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DESCRIPTION 

SEMICONDUCTOR MEMORY CARD, PIAYBACK APPARATUS, 
RECORDING APPARATUS, PLAYBACK METHOD, RECORDING METHOD, 
AND A COMPUTER-READABLE STORAGE MEDIUM 

5 

Technical Field 

The present invention relates to a semiconductor 
memory card that stores audio data, still image data and 
control data, and to a playback apparatus, recording 

10 apparatus, playback method, recording method, and 

computer-readable recording medium relating to such a 
semiconductor memory card. In particular, the present 
invention relates to improved storage of audio data, image 
data and control data distributed as contents by a content 

15 distribution service, such as an electronic music 
distribution service. 

Background Art 

Electronic music distribution enables users to 
20 purchase and receive music contents (e.g., songs and albums) 
via the Internet. Such technology has the potential to 
greatly change the market for recorded music and is gradually 
becoming possible as the necessary infrastructure is 
introduced. One way to store music contents that are 

1 
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obtained from an electronic music distribution service is 
on semiconductor memory cards whose portability makes them 
ideal. Accordingly, a great increase is expected in the 
demand for such cards. 
5 Music contents are not restricted to merely containing 

audio data. As one example, "mixed-media" audio contents 
can include related images that are to be displayed when 
music is played back. Such mixed-media audio contents can 
be used for "karaoke software" that is composed of a backing 

10 audio track and images for the lyrics of a song and a 
background. It is believed such mixed-media audio contents 
will also be subject to electronic music distribution, so 
that it is necessary to consider how such contents should 
be stored in a semiconductor memory card. 

15 The following describes howmixed-media music contents 

are stored on a recording medium, such as a CD (Compact 
Disc) , which is to say, how audio data and image data are 
conventionally stored on a recording medium. 

To enable a player to play back music and display images , 

20 a conventional mixed-media music content is recorded onto 
a recording medium as multiplexed data produced by 
multiplexing audio data for the music with image data for 
the lyrics and/ or background images . When the multiplexed 
data is reproduced, the image data can be displayed while 
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the audio data is being played back. 

A CD-Graphics disc is one example of a medium that 
enables image data to be displayed while audio data is being 
played backed by having such data multiplexed together. 
When producing a CD-Graphics disc, data is multiplexed in 
units composed of 16-bit main codes and subcodes. Audio 
data is assigned to the 16-bit main codes, while image data 
for lyrics, background images and the like is assigned to 
the subcodes . When playback commences for any of the music 
contents recorded on a CD-Graphics disc, the audio data 
assigned to the 16-bit main codes is successively played 
back while the image data assigned to the subcodes is 
successively displayed. 

When audio data and image data are multiplexed together 
in this way, it becomes necessary to provide separate images 
to each music content in a music album. This means that 
in this conventional multiplexing method, a disc producer 
has had to go to the trouble of producing at least one image 
for each music content. 

It is believed that fans of major recording artists 
will appreciate having a different image for each song (music 
content) on an album. Since such artists can expect to sell 
many copies of their albums, the cost of providing such 
extra material should be covered by sales. 
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However, minor artists cannot expect high sales for 
their work even if different images are provided for each 
song, so that the cost of providing such material may not 
be offset by sales. 

In this way, the commercial effect that results from 
the money and effort expended in the production of images 
will greatly differ depending on whether the artist is 
popular. With conventional discs, however, it is necessary 
to assign at least one image to eachmusic content, regardless 
of how popular the recording artist is or of how many sales 
can be expected. As a result, producers are dissatisfied 
with conventional media. 

Disclosure of the Invention 

It is an object of the present invention to provide 
a semiconductor memory card that can reduce the effort 
required when providing images for a plurality of audio 
contents that compose an album. 

When images are displayed during the playback of audio 
contents, images that represent the lyrics of a song should 
only be displayed during the playback of the corresponding 
song. Background images, however, may be commonly used 
during the playback of any number of songs . As one example, 
when the songwriter or artist is the same, the same picture 
of the songwriter or artist can be used as a background 

4 
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image for a number of songs. It is believed that this will 
make it easy for disc producers to store music data (audio 
objects) and image data (picture objects) together. 

The sharing of image data (still image objects) between 
5 a plurality of audio objects can be preferably achieved 
by a semiconductor memory card storing: an audio sequence 
including a plurality of audio objects; a plurality of still 
image objects; at least one piece of playback route 
information showing an order in which audio objects, out 

10 of the plurality of audio objects in the audio sequence, 
are to be played back; at least one piece of first pointer 
information, each of which corresponds to a piece of playback 
route information and specifies at least one still image 
object that should be displayed when the audio objects in 

15 the order indicated by the corresponding piece of playback 
route information are played back; and at least one piece 
of second pointer information, each of which corresponds 
to an audio object in the audio sequence and specifies at 
least one still image object that should be displayed only 

20 during playback of the corresponding audio object. 

A plurality of audio objects in an audio sequence are 
played back in accordance with a playback order given in 
a piece of playback route information. Still image objects 
that are to be displayed as background images during the 
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playback of the audio objects are indicated by the first 
pointer information corresponding to the playback route 
information. As a result, shared still image objects can 
be displayed during the playback period of the plurality 

5 of audio objects included in the audio sequence. 

Since the same images can be used for a plurality of 
tracks, the same image or images can be displayed during 
the playback of a plurality of audio objects in an audio 
sequence that corresponds to an album by a minor recording 

10 artist • This reduces the cost and effort of producing images 
for such an album. 

Conversely, a plurality of different images can be 
provided for display during the playback of each audio ob j ect 
in an audio sequence that corresponds to an album by a major 

15 recording artist. Displaying a number of different images 
for each track makes the album more appealing to customers, 
and so can improve sales. 

When there are still image objects, such as for song 
lyrics , that are to be displayed separately to the background 

20 images only during the playback of a particular track, such 
still image objects can be specified using second pointer 
information to assign the still image objects to only the 
particular track. 

Here, the semiconductor memory card may further store 
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a plurality of symbolic counters, each of which corresponds 
to a still image object and shows whether the still image 
object is specified by any of the at least one piece of 
first pointer information and the at least one piece of 
5 second pointer information and, if so, how many pieces of 
first pointer information and second pointer information 
specify the still image object. 

When deleting audio objects and audio sequences, the 
recording apparatus for a semiconductor memory card 

10 specifies the second pointer information for the deleted 
audio objects and audio sequences and the first pointer 
information for any deleted audio sequence. The recording 
apparatus then decrements the numbers assigned to still 
image objects to show how many pieces of first pointer 

15 information and second pointer information specify each 
object. When the number assigned to any still image object 
reaches zero, the recording apparatus assumes that no piece 
of first pointer information or second pointer information 
specifies the still image object and so deletes the still 

20 image object. By deleting unused still image objects in 
this way, the storage capacity of a semiconductor memory 
card can be used more efficiently. 

25 
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Brief Description Of The Drawings 

These and other objects^ advantages and features of 
the invention will become apparent from the following 
description thereof taken in conjunction with the 
5 accompanying drawings which illustrate a specific 
embodiment of the invention. In the Drawings: 

FIG. 1 shows the appearance of a flash memory card 
31 when viewed from above; 

FIG. 2 shows the construction of the flash memory card 
10 31 when viewed from below; 

FIG. 3 shows the hierarchical composition of the flash 
memory card 31 in the embodiments; 

FIG. 4A shows the special region, the authentication 
region and the user region provided in the physical layer 
15 of the flash memory card 31; 

FIG. 4B shows the composition of the authentication 
region and the user region in the file system layer; 

FIG . 5 shows the detailed composition of the file system 
layer; 

20 FIG. 6 is a representation of when the AOB file 

"AOBOOl.SAl" is divided into five parts that are stored 
in clusters 003, 004, 005, OOA, and OOC; 

FIG. 7 shows one example of the settings of the 
directory entries and file allocation table when the AOB 

25 file "AOBOOl.SAl" is recorded in a plurality of clusters; 

8 
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FIGs. 8A and 8B show what directories are provided 
in the user region and the authentication region in the 
file system layer when the above two types of data are recorded 
in the application layer, as well as what kind of files 
5 are recorded in which directories; 

FIG. 9 shows the correspondence between the file 
"AOBSAl.KEY" and the AOB files in the SD__Audio directories; 

FIG. 10 shows the hierarchical composition of the data 
in an AOB file; 

10 FIG. IIA shows the parameters stipulated by ISO/IEC 

13818-7 standard in tabular form; 

FIG. IIB shows the parameters that should be used when 
encoding a file in MPEG-Layer 3 (MP3) format in tabular 
form; 

15 FIG. lie shows the parameters that should be used when 

encoding a file in Windows Media Audio (WMA) format in tabular 
form; 

FIG. 12 shows the detailed construction of an 
AOB_FRAME; 

20 FIG. 13 shows how the byte length of the audio data 

in each of three AOB_FRAMEs is set; 

FIG. 14 shows the correspondence between the 

sampling^f requency and the number of AOB_FRAMEs included 

in an AOB_ELEMENT; 
25 FIG. 15 shows examples of the playback periods of 

9 
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AOB_ELEMENTs and the playback periods of AOB_FRAMEs; 

FIG. 16 shows what is reproduced when the AOBs and 
AOB_BLOCKs recorded in an AOB file are consecutively played 
back; 

FIG. 17 shows the hierarchical composition of the • 
PlaylistManager and TrackManager used in the embodiments 
in detail; 

FIG. 18 shows the sizes of the PlaylistManager and 
the TrackManager; 

FIG. 19 shows the correspondence between the TKIs shown 
in FIG. 17 and the AOBs and AOB files shown in FIG. 16; 

FIG. 20 shows the detailed data composition of the 
TKTMSRT shown in FIG. 17; 

FIG. 21 shows one example of the TKTMSRT; 

FIG. 22 shows the detailed composition of the TKGI; 

FIGs. 23A and 23B show the composition of the BIT; 

FIG. 23C shows the Time_Length field; 

FIG. 24 shows cluster 007 to OOE into which the AOB 
composed of A0B_ELEMENT#1 to A0B_ELEMENT#4 are stored; 

FIG. 25 shows how the next AOB_FRAME#x+l to be played 
back is set when forward search is performed starting from 
the AOB_FRAME#x in an arbitrary AOB_ELEMENT#y in an AOB; 

FIGs. 26A and 26B shows how an AOB^ an AOB_ELEMENT, 
and an AOB_FRAME that correspond to an arbitrary playback 
time code are specified; 
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FIGS. 27A and 27B show the deletion of a track; 

FIG. 28A shows the TrackManager after the deletion 
of a track has been performed several times; 

FIG. 28B shows how a new TKI and AOB file are written 
5 when "Unused" TKIs are present in the TrackManager; 

FIGS . 29A and 29B show the TKIs are set when two tracks 
are combined to produce a new track; 

FIG. 30A shows a Typel AOB; 

FIG. 30B shows Type2 AOBs; 
10 FIG. 31A shows the combining of a plurality of tracks 

into a single track for a combination of a Typel+ Type2+ 
Type2+ Typel AOB; 

FIG- 31B shows the combining of a plurality of tracks 
into a single track for a combination of a Typel+ Type2+ 
15 Type2+ Type2-f Typel AOB; 

FIG. 32A shows a pattern where a Typel AOB is present 
at the end of a preceding track and a Typel AOB is present 
at the start of a next track; 

FIG. 32B shows a pattern where a Typel AOB is present 
20 at the end of a first track and a Type2 AOB is present at 
the start of a next track; 

FIG. 32C shows a pattern where a Typel and Type2 AOB 
are present at the end of a first track and a Typel AOB 
is present at the start of a next track; 
25 FIG. 32D shows a pattern where a Typel and Type2 AOB 



11 



wo 00/74061 



PCT/JPOO/03300 



■I li 

are present at the end of a first track and a Type2 and 
a Typel AOB is present at the start of a next track; 

FIG. 32E shows a pattern where two Type2 AOBs are 
present at the end of a first track and a Typel is present 
5 at the start of a next track; 

FIGS . 33A and 33B show the division of a track to produce 
two tracks; 

FIGS. 34A and 34B show the content of the SD_Audio 
directory entries in the SD_Audio directory including the 
10 AOB file "AOB003.SA1" before and after the division of the 
track; 

FIG. 35A shows the division of an AOB midway through 
A0B_ELEMENT#2; 

FIG. 35B shows the two AOBs, A0B#1 and A0B#2, obtained 
15 by dividing an AOB midway through A0B_ELEMENT#2; 

FIG. 36 shows how the BIT is set when an AOB is divided 
as shown in FIG. 35; 

FIG. 37 shows a specific example of changes in the 
BIT before and after division; 
20 FIG. 38 shows a specific example of changes in the 

TKTMSRT before and after division; 

FIG. 39A shows the format of a DPL_TK_SRP; 
FIG. 39B shows the format of a PL_TK_SRP; 
FIG. 40 shows -the interrelation between the 
25 Default_Playlist_Information, the TKIs, and the AOB files; 
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FIG. 41 shows example settings for the 
Default_Playlist and several PLIs; 

FIG. 42 shows how the DPL_TK_SRPs correspond to TKIs 
using the same notation as FIG. 40; 

FIGS. 43A and 43B show how the order of tracks is 
rearranged; 

FIGS. 44A and 44B show how the Def ault_Playlist, 
TrackManager, and AOB files will be updated when 
DPL_TK_SRP#2 andTKl#2 are deleted from the Default_Playlist 
shown in FIG. 40; 

FIGS. 45A and 45B show how a new TKI and DPL_TK_SRP 
are written when an "Unused" TKI and DPL_TK_SRP are present; 
FIGS. 46A and 46B show how tracks are combined; 

FIGS. 47A and 47B shows how a track is divided; 

FIG. 48 shows the appearance of a portable playback 
apparatus for the flash memory card 31 of the present 
embodiments; 

FIG. 49 shows one example of the display on the LCD 
panel when a playlist is selected; 

FIGS. 50A to 50E show examples of the display on the 
LCD panel when a track is selected; 

FIGS. 51A to 51C show example operations of the jog 

dial; 

FIG. 52 shows the internal construction of the 
reproduction apparatus; 
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FIG, 53 shows how data is transferred in and out of 
the double buffer 15; 

FIG, 54A and 54B shows how areas in the double buffer 
15 are cyclically allocated using ring pointers; 
5 FIG. 55 is a flowchart showing the AOB file read 

procedure; 

FIG. 56 is a flowchart showing the AOB file output 
procedure; 

FIG. 57 is a flowchart showing the AOB file output 
10 procedure; 

FIG. 58 is a flowchart showing the AOB file output 
procedure; 

FIGS. 59A to 59D show how the playback time code 
displayed in the playback time code frame on the LCD panel 
15 5 is updated in accordance with the updating of the variable 
Play^time; 

FIG. 60 is a flowchart shows the processing of the 
CPU 10 when the forward search function is used; 

FIGS. 61A to 61D show how the playback time code is 
20 incremented when the forward search function is used; 

FIGS. 62A and 62B show specific examples of how the 
time search function is used; 

FIG. 63 is a flowchart showing the processing in the 
editing control program; 
25 FIG. 64 is a flowchart showing the processing in the 
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editing control program; 

FIG. 65 is a flowchart showing the processing in the 
editing control program; 

FIG, 66 shows one example of a recording apparatus 
for recording data onto the flash memory card 31; 

FIG. 67 shows the hardware configuration of the 
recording apparatus; 

FIG. 68 is a flowchart showing the processing during 
recording; 

FIG. 69 shows the internal construction of a flash 
memory card according to the second embodiment of the present 
invention; 

FIGS. 70A and 70B show the internal composition of 
the user data area and the protected area in the file system 
layer; 

FIG. 71A shows the internal composition of a 
"POBXXX.JPG" file; 

FIG. 71B shows the internal composition of a POB file 
that includes encrypted still image data; 

FIG. 71C shows an example of a POB file that stores 
a file path in place of an encrypted data body; 

FIG. 72 shows the detailed compositions of the 
PlaylistManager and TrackManager in the second embodiment; 

FIG. 73 shows how the POB files shown in FIG. 70 are 
specified by TKI_POB_SRPs/ PLI_POB_SRPs, and 

15 
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FIG. 74 shows the data compositions of the TKI_POB_ATR 
and a TKI_POB_SRP; 

FIG. 75 shows example settings of the TKI_POB_SRPs 
5 for TKI#1 to TKI#3 in the TrackManager; 

FIG. 76 shows example settings of the TKI_POB_SRPs 
for TKI#4 to TKI#8 in the TrackManager; 

FIG. 77 shows the DPLI_POB_SRPs and DPLI_POB_ATR 
included in the DPLGI; 
10 FIG. 78 shows an example setting of twenty 

DPLI_POB_SRPs included in the 
Default_Playlist_Information; 

FIG. 79 is a timing chart showing how a combined image 
is formed when a POB specified by a DPLI_POB_SRP included 
15 in the Def ault_Playlist_Inf ormation is used as a background 
image and a POB specified by a TKI_POB_SRP included in the 
TrackManager is used as a foreground image; 

FIG. 80 shows how a background image and foreground 
image are combined at a point six minutes after the start 
20 of playback according to the Def ault_Playlist_Inf ormation; 

FIG. 81 shows how a background image and foreground 
image are combined at a point sixteen minutes after the 
start of playback according to the 
Def ault_Playlist_Information; 

16 
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FIG. 82 shows the PLI_POB_SRPs and PLI_POB_ATR 
included in a PLGI; 

FIG . 83 shows an example setting of twenty PLI_POB_SRPs 
included in a PLI; 

FIG. 84 is a timing chart showing how a combined image 
is formed when a POB specified by a PLI_POB_SRP included 
in a PLI is used as a background image and a POB specified 
by a TKI_POB_SRP included in the TrackManager is used as 
a foreground image; 

FIG. 85 shows how a background image and foreground 
image are combined at a point six minutes after the start 
of playback according to a PLI; 

FIG. 86 shows how a background image and foreground 
image are combined at a point sixteen minutes after the 
start of playback according to a PLI; 

FIG. 87 shows an example where the number of POB files 
is reduced by having a number of DPLI_POB_SRPs in the 
Default_Playlist_Information specify the same POB files; 

FIG. 88 is a timing chart showing how a combined image 
is formed when a POB specified by a DPLI_POB_SRP included 
in the Def ault_Playlist_Inf ormation is used as a background 
image and a POB specified by a TKI_POB_SRP included in the 
TrackManager is used as a foreground image; 

FIG. 89 shows the internal composition of the POBMG; 
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FIG. 90 shows how the playback apparatus of the second 
embodiment is used; 

FIG. 91 shows the external appearance of only the 
playback apparatus of the second embodiment; 
5 FIG . 92 shows the internal construction of the playback 

apparatus of the second embodiment; 

FIG. 93A shows how the still images stored in the 
plurality of VRAMs 61 can be laid on top of one another; 

FIG. 93B also shows how the still images stored in 
10 the plurality of VRAMs 61 can be laid on top of one another; 

FIG. 94 is a flowchart showing the foreground image 
display procedure; 

FIG. 95 is a flowchart showing the background image 
display procedure; 
15 FIG. 96 is a flowchart showing the background image 

display procedure; 

FIGS. 97A to 97C show what kind of combined image is 
displayed on the LCD panel 5 due to the processing in the 
flowcharts in FIGS. 94 and 95 that has a POB specified by 
20 a TKI_POB_SRP displayed as a foreground image and a POB 
specif ied by a DPLI_POB_SRP displayed as a background image; 

FIGS. 98A to 98C show what kind of combined image is 
displayed on the LCD panel 5 due to the processing in the 
flowcharts in FIGS. 94 and 96 that has a POB specified by 
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a TKI_POB_SRP displayed as a foreground image and a POB 
specified by a PLI_POB_SRP displayed as a background image; 

FIG. 99 is a flowchart showing the procedure used by 
the recording apparatus of the second embodiment; 
5 FIG. lOOA shows an example of the phrase timing table; 

and 

FIG. lOOB shows an example of the highlight coordinate 
table . 

10 Best Mode for Carrying Out the Invention 

The following describes a semiconductor memory card 
(flash memory card) that is an embodiment of the present 
invention,, with reference to the attached figures. 

The following paragraphs are arranged into a hierarchy 
15 using reference numbers with the notation given below. 

{xl-x2_x3-x4} 

The length of a reference number shows the level of 
20 the topic in the hierarchy. As a specific example, the 
number xl is the number of drawing that is being referred 
to in the explanation. The drawings attached to this 
specification have been numbered in the order in which they 
are referred to in the specification, so that the order 
25 of the drawings roughly matches the order of the explanation . 

19 
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The explanation of certain drawings has been divided into 
sections, with the reference number x2 giving the section 
number of a section in the explanation of a drawing indicated 
by the reference number xl. The reference number x3 shows 
5 the number of an additional drawing that is provided to 
show the details of the section indicated by the section 
number x2. Finally, the reference number x4 shows the number 
of a section in the explanation of this additional drawing. 

10 FIRST EMBODIMENT 

{1-1^2} External i^pearance of the Flash Itemory Card 31 

The present explanation starts with the external 
appearance of the flash memory card 31. FIG. 1 shows the 
appearance of the flash memory card 31 when viewed from 

15 above, while FIG. 2 shows the construction of the flash 
memory card 31 when viewed from below. As shown in FIGS. 
1 and 2, the flash memory card 31 is around the same size 
as a postage stamp, and so is large enough to be held by 
hand. Its approximate dimensions are 32.0mm long, 24.0mm 

20 wide, and 2.0mm thick. 

The flash memory card 31 can be seen to have nine 
connectors on its bottom edge for connecting the card to 
a compatible device and a protect switch 32 on one side 
to enable the user to set whether overwriting of the stored 

25 content of the flash memory card 31 is permitted or 
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prohibited. 

{3-1} Physical Construction of the Flash Memory Card 31 

FIG. 3 shows the hierarchical structure of the 
5 semiconductor memory card (hereafter referred to as the 
"flash memory card 31") of the present embodiment. As shown 
in FIG. 3^ the flash memory card 31 is constructed with 
a physical layer^ a file system layer and an application 
layer in the same way as a DVD (Digital Video Disc) , though 
10 the logical and physical constructions of these layers are 
very different to those on a DVD. 

{3-2} Physical Layer of the Flash Memory Card 31 

The following describes the physical layer of the flash 
15 memory card 31 . The flash memory is composed of a plurality 
of sectors, each of which stores 512 bytes of digital data. 
As one example, a 64MB flash memory card 31 will have a 
storage capacity of 67,108,864 (=64*1,024*1,024) bytes, 
so that this card will include 131, 072 (=67108864/512) valid 
20 sectors. Once the number of 

replacement sectors, which are provided for use in case 
of errors, is subtracted, the remaining number of valid 
sectors into which various kinds of data can be written 
is around 128,000. 

25 
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{3-2_4A-l) Three Regions in the Physical Layer 

The three regions shown in FIG. 4A are provided in 
the storage area composed of these valid sectors. These 
regions are the "special region", the "authentication 
5 region" and the "user region", and are described in detail 
below. The user region is characterized in that a device 
to which the flash memory card 31 is connected can freely 
read or write various kinds of data from or into this region. 
Areas within the user region are managed by a file system. 

10 The special region stores a media ID that is a value 

uniquely assigned to each flash memory card 31 . Unlike the 
user region, this region is read-only, so that the media 
ID stored in the special region cannot be changed. 

The authentication region is a writeable region, like 

15 the user region. This region differs from the user region 
in that a device connected to the flash memory card 31 can 
access (i.e., read or write data in) the authentication 
region only if the flash memory card 31 and the device have 
first confirmed that each other is an authentic device. 

20 In other words, data can only be read from or written into 
the authentication region if mutual authentication has been 
successfully performed by the flash memory card 31 and the 
device connected to the flash memory card 31. 

25 
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{3-2_4A-2> Uses of the Three Regions 

in the Physicstl Layer 

When the device connected to the flash memory card 
31 writes data into the flash memory card 31, the region 
used to store this data will depend on whether copyright 
protection is necessary for the data being written. When 
data that requires copyright protection is written into 
the flash memory card 31, the data is encrypted using a 
predetermined encryption key (called a "FileKey") before 
being written into the user area . This FileKey can be freely 
set by the copyright holder and, while the use of this FileKey 
provides some level of copyright protection, the FileKey 
used for encrypting the written data is itself encrypted 
to make the copyright protection more secure. Any value 
obtained by subjecting the media ID stored in the special 
region into a predetermined calculation can be used to 
encrypt the FileKey . The encrypted FileKey produced in this 
way is stored in the authentication region. 

Since data that requires copyright protection is 
subjected to a two-step encryption process where the data 
is encrypted using a FileKey that is itself encrypted based 
on the media ID, copyright infringement, such as the 
production of unauthorized copies of this data, will be 
extremely difficult. 
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{3-2_4B-l} Overview of the Pile System 

As can be understood, the construction of the physical 
layer of the flash memory card 31 strengthens the copyright 
protection of the data written in the flash memory card 
5 31. The following describes the file system layer present 
on this physical layer. While the file system layer of a 
DVD uses a UDF (Universal Disk Format) -type file system, 
the file system layer of the flash memory card 31 uses a 
FAT (File Allocation Table) -type file system, as described 
10 in ISO/IEC 9293. 

FIG. 4B shows the construction of the authentication 
region and the user region in the file system layer. As 
shown in FIG. 4B, the authentication region and the user 
region in the file system each include "partition boot 
15 sectors", a "file allocation table (FAT)", a "root 
directory", and a "data region", meaning that the 
authentication region and the user region have the same 
construction. FIG. 5 

shows the various parts of these file systems in more detail. 
20 The following describes the construction of the user region 
with reference to FIGS. 4A, 4B and 5. 

{3-2_4B-2) Partition Boot Sectors 

The partition boot sectors are sectors that store the 
25 data that will be referred to by a standard personal computer 

24 
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that is connected to the flash memory card 31 when the flash 
memory card 31 is set as the boot disk for the operating 
system (OS) of the personal computer. 

5 {3-2_4B-3_5} Data Region 

The data region can be accessed by a device connected 
to the flash memory card 31 in units no smaller than a 
"cluster". While each sector in the flash memory card 31 
is 512 bytes in size, the cluster size is 16KB, so that 
10 the file system layer reads and writes data in units of 
32 sectors. 

The reason the cluster size is set at 16KB is that 
when data is written onto the flash memory card 31, part 
of the data stored in the flash memory card 31 first has 

15 to be erased before the write can be performed. 

The smallest amount of data that can be erased in the 
flash memory card 31 is 16KB, so that setting the smallest 
erasable size as the cluster size means that data writes 
can be favorably performed. The arrow ff2 drawn using a 

20 broken line in FIG. 5 shows the plurality of clusters 
002, 003,004,005 . . . included in the data region. The 
numbers 002,003,004,005,006,007,008 . . . used in FIG. 
5 are the three-digit hexadecimal cluster numbers that are 
exclusively assigned to identify each cluster. Since the 

25 smallest unit by which access can be performed is one cluster, 



wo 00/74061 



PCT/JPOO/03300 



storage positions within the data region are indicated using 
cluster numbers. 

{3-2_4B-4_5} Pile Allocation System 

5 The file allocation system has a file system 

construction in accordance with ISO/IEC 9293 standard, and 
so is made up of a plurality of FAT values. Each FAT value 
corresponds to a cluster and shows which cluster should 
be read after the cluster corresponding to the FAT value. 

10 The arrow ffl shown by a broken line in FIG. 5 shows the 
plurality of FAT values 002,003,004,005 . . . that are 
included in the file allocation table. The numbers 
002, 003, 004, 005 . . . assigned to each FAT value show which 
cluster corresponds to each FAT, value and therefore are 

15 the cluster numbers of the clusters corresponding to the 
FAT values. 

{3-2_4B-5_5-l} Root Directory Entries 

The "root directory entries" are information showing 
20 what kinds of files are present in the root directory. As 
specific examples, the "filename" of an existing file, its 
"filename extension", the "revision time/date" and "number 
of first cluster in file" showing where the start of the 
file is stored can be written as the root directory entry 
25 of a file. 

26 • 



wo 00/74061 



PCT/JPOO/03300 



i3-2_4B-5_S-2} Directory Entries for Subdirectories 

Information relating to files in the root directory 
is written as root directory entries, though information 
5 relating to subdirectories is not written as the root 
directory entries. Directory entries for subdirectories 
are instead produced in the data region. In FIG. 5, the 
SD-Audio directory entry given in the data region is one 
example of a directory entry for a subdirectory. Like a 
10 root directory entry, an SD-Audio directory entry includes 
the "filename" of a file present in this subdirectory, its 
"filename extension", the "revision time/date" and "number 
of first cluster in file" showing where the start of the 
file is stored. 

15 

{3-2_4B-5_6-l} Storage Format for AOB Piles 

The following describes the file storage method by 
showing how a file named "AOBOOl.SAl" is stored in the 
SD-Audio directory, with reference to FIG. 6. Since the 

20 smallest unit by which the data region can be accessed is 
one cluster, the file "AOBOOl.SAl" needs to be stored in 
the data region in parts that are no smaller than one cluster . 
The file "AOBOOl.SAl" is therefore stored having first been 
divided into clusters. In FIG. 6, the file "AOBOOl.SAl" 

25 is divided into five parts in keeping with the cluster size, 
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and the resulting parts are stored into the clusters numbered 
003, 004, 005, OOA, and OOC. 

{3-2_4B-5_7-l) Storage Format for AOB Piles 

5 When the file "AOBOOl.SAl" is divided up into parts 

and stored, a directory entry and the file allocation table 
need to be set as shown in FIG. 7. FIG. 7 shows one example 
of how the directory entry and file allocation table need 
to be set when the file "AOBOOl.SAl" is stored having been 

10 divided up into parts and stored. In FIG. 7, the start of 
the file "AOBOOl.SAl" is stored in cluster 003, so that 
cluster number 003 is written into "the number of first 
cluster in file" in the SD-Audio directory entry to indicate 
the cluster storing the first part of the file. As shown 

15 in FIG. 7, the following parts of the file "AOBOOl.SAl" 
are stored in clusters 004 and 005. As a result, while the 
FAT value 003(004) corresponds to cluster 003 that stores 
the first part of the file "AOBOOl.SAl", this value indicates 
cluster 004 as the cluster storing the next part of the 

20 file "AOBOOl.SAl". In the same way, while the FAT values 
004(005) and 005 (OOA) respectively correspond to clusters 
004 and 005 that store the next parts of the file "AOBOOl . SAl" , 
these values respectively indicate cluster 005 and cluster 
OOA as the clusters storing the next parts of the file 

25 "AOBOOl.SAl". By reading the clusters with the cluster 
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numbers written into these FAT values in order as shown 
by the arrows fkl, fk2, fk3, fk4, fkS • . . in FIG. 1, 
all of the parts produced by dividing the file "AOBOOl.SAl" 
can be read. As explained above, the data region of the 

5 flash memory card 31 is accessed in units of clusters, each 
of which is associated with a FAT value. Note that the FAT 
value that corresponds to the cluster storing the final 
part of an AOB file (the cluster OOC in the example shown 
in FIG. 7) is set the cluster number FFF to show that the 

10 corresponding cluster stores the final part of a file. 

This completes the explanation of the file system in 
the flash memory card 31 of the present invention. The 
following describes the application layer that exists on 
this file system. 

15 

{3-3} Overview of the implication Layer 

in the Flash Memory Card 31 

An overview of the application layer in the flash memory 
card 31 is shown in FIG. 3. As shown by the arrow PN2 drawn 

20 with a broken line in FIG. 3, the application layer in the 
flash memory card 31 is composed of presentation data and 
navigation data that is used to control the playback of 
the presentation data. As shown by the arrow PN2, the 
presentation data includes sets of audio objects (AOB sets) 

25 that are produced by encoding audio data that represents 
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musiC/ for example. The navigation data includes a 
"PlaylistManager" (PLMG) and a "TrackManager" (TKMG) . 

{3-3_8A,B-l) Directory Coxnposition 

5 FIGS. 8A and 8B show what kind of directories are 

present in the user region and the authentication region 
in the file system layer when these two types of data are 
stored in the application layer, as well as showing what 
files are arranged into these directories. 

10 The filenames "SD_AUDIO. PLM" and "SD_AUDIO.TKM" in 

FIG. 8A indicate the files in which the PlaylistManager 
(PLMG) and TrackManager (TKMG) composing the navigation 
information are stored. Meanwhile, the filenames 
"AOBOOl . SAl " , "AOB002 . SAl" , "AOB003 . SAl " , 

15 "AOB004.SA1", . . . indicate the files ("AOB" files) 
storing the audio objects that are the presentation data. 
The letters "SA" in the filename extension of the filename 
"AOBOxx.SAl" are an abbreviation for "Secure Audio", and 
show that the stored content of this file requires copyright 

20 protection. Note that while only eight AOB files are shown 
in the example in FIG. 8A, a maximum of 999 AOB files can 
be stored in an SD-Audio directory. 

When copyright protection is required for presentation 
data, a subdirectory called an "SD-Audio directory" is 

25 provided in the authentication region and an encryption 

30 
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key storing file "AOBSAl.KEY" is produced in this SD-Audio 
directory, 

FIG. 8B shows the encryption key storing file 
"AOBSAl.KEY" that is stored under the "SD-Audio" legend 
5 (i.e. , within the "SD-Audio directory") . This encryption 
key storing file "AOBSAl.KEY" stores a sequence of 
encryption keys that is produced by arranging a plurality 
of encryption keys into a predetermined order. 

The SD-Audio directory shown in FIGS. 8A and 8B is 

10 stored in a server computer managed by a record label that 
uses electronic music distribution . When a consumer orders 
a music content, the corresponding SD-Audio directory is 
compressed, encrypted and transmitted to the consumer via 
a public network. The consumer's computer receives this 

15 SD-Audio directory, decrypts it, decompresses it and so 
obtains the original SD-Audio directory. Note that the 
expression "public network" here refers to any kind of 
network that can be used by the public, such as a wired 
communication network, e.g., an ISDN network, or a wireless 

20 communication network, e.g., a mobile telephone system. 
It is also possible for a consumer's computer to download 
an AOB file from a server computer operated by a record 
label and then produce an SD-Audio directory, such as that 
shown in FIGS. BA and SB, in the flash memory card 31. 

25 
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{3-3_9**l} Correspondence between the 

"AOBSAl.KEY" file and the AOB files 

FIG. 9 shows the correspondence between the 
"AOBSAl.KEY" file in the SD-Audio directory and the AOB 
5 files. The FileKeys used when encrypting files in the user 
region shown in FIG. 9 are stored in the corresponding 
encryption key storing file in the authentication region. 

The encrypted AOB files and the encryption key storing 
file correspond according to the predetermined rules (1), 
10 (2), and (3) described below. 

(1) The encryption key storing file is arranged into 
a directory with the same directory name as the directory 
in which the encrypted file is stored. In FIG. 9, AOB files 
are arranged into the SD-Audio directory in the user region 

15 and the encryption key storing file is arranged into a 
directory called the SD-Audio directory in the 
authentication region, in accordance with this rule. 

(2) The encryption key storing file is given a filename 
produced by combining the first three letters of the filename 

20 of the AOB files in the data region with the predetermined 
".key" extension. When the filename of an AOB file is 
"AOBOOl.SAl", the encryption key storing file is given the 
filename "AOBSAl.KEY" produced by adding the first three 
characters "AOB", "SAl", and the extension ".key", as shown 

25 by the arrows nkl and nk2 in FIG. 9. 
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(3) The filename of an AOB file is given a serial number 
showing the position of the FileKey corresponding to this 
audio object in the sequence of encryption keys given in 
the encryption key storing file. 
5 The "File Key Entries #1, #2, #3 . . . #8" show the 
first positions of the regions in which the respective 
FileKeys in the encryption key storing file are stored. 
Meanwhile, the filenames of AOB files are assigned the serial 
numbers "001", "002", "003", "004" These serial 

10 numbers show the positions of the corresponding FileKeys 
in the encryption key sequence, so that the FileKey that 
was used to encrypt each AOB file will be present in the 
"FileKey Entry" with the same serial number. In FIG. 9, 
the arrows Akl, Ak2, AkS, . . . show the correspondence 

15 between AOB files and FileKeys. In other words, the file 
"AOBOOl.SAl" corresponds to the FileKey whose storage 
position is indicated by the "FileKey Entry#l", the file 
"AOB002.SA1" corresponds to the FileKey whose storage 
position is indicated by the "FileKey Entry#2", and the 

20 file "AOB003.SA1" corresponds to the FileKey whose storage 
position is indicated by the "FileKey Entry#3". As can be 
understood from rule (3) , different FileKeys are used to 
encrypt different AOB files, with these FileKeys being 
stored in "FileKey Entries" with the serial numbers "001", 

25 "002", "003", "004" etc., given in the filenames of the 
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corresponding AOB files. 

Since each AOB file is encrypted using a different 
FileKey, the exposure of the encryption key used for one 
AOB file will not enable users to decrypt other AOB files. 
5 This means that when AOB files are stored in an encrypted 
form on a flash memory card 31, the damage caused by the 
exposure of one FileKey can be minimized. 

{3-3_10-l} Internal Composition of an AOB file 

10 The following describes the internal composition of 

an AOB file. FIG. 10 shows the hierarchical data structure 
of an AOB file. The first level in FIG. 10 shows the AOB 
file, while the second level shows the audio object (AOB) 
itself. The third level shows the AOB_BLOCKs, the fourth 

15 level an AOB_ELEMENT, and the fifth level an A0B__FR7^E. 

The AOB_FRAME on the fifth level in FIG. 10 is the 
smallest unit composing the AOB, and is composed of audio 
data in ADTS (Audio Data Transport Stream) format and an 
ADTS header. Audio data in ADTS format is encrypted 

20 according to MPEG2-AAC (Low Complexity Profile) format and 
is stream data that can be played back at a transfer rate 
of 16Kbps to 144Kbps. Note that the transfer rate for PCM 
(Pulse Code Modulation) that is recorded on a conventional 
compact disc is 1 . 5Mbps , so that data in ADTS format generally 

25 uses a lower transfer rate than PCM. The data construction 



wo 00/74061 



PCT/JPOO/03300 



of a sequence of AOB_FRAMEs is the same as the sequence 
of audio frames included in an audio data transport stream 
distributed by an electronic music distribution service. 
This means that the audio data transport stream to be stored 
as AOB_FRAME sequence is encoded according to MPEG2-ACC 
standard, encrypted, and transmitted on a public network 
to the consumer. AOB files are produced by dividing the 
transmitted audio data transport stream into a sequence 
of AOB_FRAMEs and storing these AOB_FRAMEs. 

{3-3__10-l_ll) MPEG2-AAC 

MPEG2-AAC is described in detail in ISO/IEC 
13818-7 : 1997 (E) "Information Technology - Generic Coding 
of Moving Pictures and Associated Audio Information - Part7 
Advanced Audio Coding (AAC)". 

It should be noted that audio objects can only be 
compressed according to MPEG2-AAC using the parameters in 
the parameter table shown in FIG. IIA that is defined in 
ISO/IEC13818-7 . This parameter table is composed of 
"Parameter" column, a "Value" column, and a "Comment" 
column . 

The legend "profile" in the Parameter column shows 
the only LC-prof ile can be used, as stipulated under ISO/IEC 
13838-7. The legend "sampling_f requency#index" in the 
Parameter colximn shows that the sampling frequencies "48kH2, 
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44.1kHz, 32kHz, 24kHz, 22.05kHZ, and 16kHz" can be used. 

The legend ••nuinber_of_data_block_in_frame" in the 
Parameter column shows that the ratio of one header to one 
raw_data_block is used. 

5 Note that while this explanation describes the case 

where AOB_FRAMEs are encoded according to MPEG-AAC format, 
AOB_FRAMEs may instead be encoded according to another 
format, such as MPEG- Layer 3 (MP3) format or Windows Media 
Audio (WMA) . When doing so, the parameters shown in the 

10 parameter tables of FIG. IIB or FIG. IIC must be used. 

{3-3_10-2_12} Composition of an AOB_FI»ME 

While each AOB_FRAME includes audio data that is 
encoded according to the restrictions described above, the 

15 data length of the audio data in each AOB_FRAME is restricted 
to a playback time of only 20ms. However, since MPEG2-AAC 
is a variable bitrate (VBR) encoding method, the data length 
of the audio data in each AOB_FRAME will vary . The following 
describes the composition of an AOB_FRAME, with reference 

20 to FIG. 12. 

The first level in FIG . 12 shows the overall composition, 
while the second level shows how each part of an AOB FRAME 
is encrypted. As can be seen from the drawing, the ADTS 
header corresponds to a non-encrypted part . The audio data 

25 includes both an encrypted part and a non-encrypted part. 
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The encryptedpart of the audio data is composed of a plurality 
of eight-byte pieces of encrypted data, each of which is 
produced by encrypting an eight-byte piece of audio data 
using a 56-bit FileKey, When encryption is performed on 

5 64-bit pieces of audio data, the non-encrypted part of the 
audio data is simply a final part of the data that cannot 
be encrypted due to it being shorter than 64 bits. 

The third level in FIG. 12 shows the content of the 
ADTS header that is in the non-encrypted part of the AOB_FRAME . 

10 The ADTS header is seven bytes long, and includes a 12-bit 
synch word (set at FFF) , the data length of the audio data 
in this AOB_FRAME, and the sampling frequency used when 
the audio data was encoded. 

15 {3-3_10-3_13} Setting of the Byte Length of an A0B_PR3iME 

FIG. 13 shows how the byte length of the audio data 
in each of three AOB_FRAMEs is set. In FIG. 13, the data 
length of audio data#l included in A0B_FRAME#1 is xl, the 
data length of audio data#l included in A0B_FRAME#2 is x2, 

20 and the data length of audio data#l included in A0B__FRAME#3 
isx3. When the data lengths xl, x2, and x3 are all different, 
the data length xl will be written in the ADTS header of 
A0B_FRAME#1, the data length x2 will be written in the ADTS 
header of A0B_FRAME#2 , and the data length x3 will be written 

25 in the ADTS header of A0B_FRAME#3. 
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Although the audio data is encrypted, the ADTS header 
is not, so that a playback device can know the data length 
of the audio data in an AOB_FRAME by reading the data length 
given in the ADTS header of the AOB_FRAME. 
5 This completes the explanation of an AOB_FRAME. 

{3-3_10-4) AOB_ELEMENT 

The following describes the AOB_ELEMENT shown on the 

fourth level in FIG. 10. 
10 An "AOB_ELEMENT" is a group of consecutive AOB_FRAMEs . 

The number of AOB_FRAMEs in an AOB_ELEMENT depends on the 

value set as the sampling_f requency_index shown in FIG. 

IIA and the encoding method used. The number of AOB_FRAMEs 

in an AOB_ELEMENT is set so that the total playback time 
15 of the included AOB_FRAMEs will be around two seconds, with 

this number depending on the sampling frequency and encoding 

method used. 

{3-3_10-5_14) Nxanber of 2^0B_PRAMEs in an AOB_ELEMENT 

20 FIG. 14 shows the correspondence between the sampling 

frequency and the number of AOB_FRAMEs included in an 
AOB_ELEMENT. The number N given in FIG. 14 represents the 
playback period of an AOB_ELEMENT in seconds . When MPEG-ACC 
is used as the encoding method, the value of N is "2". 

25 When the sampling_f requency is 48kH2, the number of 
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AOB_FRAMEs included in an AOB_ELEMENT is given as 94 (=47*2) , 
while when the sampling_f requency is 44.1kHz, the number 
of A0B_FR7^Es included in an AOB_ELEMENT is given as 
86 (=43*2). When the sampling_f requency is 
5 32kH2, the number of AOB_FRAMEs is given as 64 (=32*2) , when 
the sampling_f requency is 24kHz, the number of AOB_FRAMEs 
is given as 48 (=24*2), when the sampling_f requency is 
22.05kHz, the number of AOB_FRAMEs is given as 44 (=22*2), 
and when the sampling_f requency is 16kHz, the number of 

10 AOB_FRAMEs included in an AOB_ELEMENT is given as 32 (=16*2) . 
However, when an editing operation, such as the division 
of an AOB, has been performed, the number of AOB_FRAMEs 
included in an AOB_ELEMENT at the start or end of an AOB 
may be less than a number calculated in this way. 

15 While no header or other special information is 

provided for each AOB_ELEMENT, the data length of each 
AOB_ELEMENT is instead shown by a time search table. 

{3"-3_10-6_15) One Example of the 
20 Playback Periods of AOB_ELEMENTs and AOB_FRAMEs 

FIG. 15 shows one example of the playback periods of 
AOB^ELEMENTs and AOB_FRAMEs. The first level in FIG. 15 
shows a plurality of AOB_BLOCKs, while the second level 
shows a plurality of AOB_ELEMENTs . The third level shows 
25 a plurality of AOB_FRAMEs. 
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As shown in FIG. 15, an AOB_ELEMENT has a playback 
period of around 2,0 seconds, while an AOB_FRAME has a 
playback period of 20 milliseconds. The "TMSRT_entry" 
given to each AOB_ELEMENT shows that the data length of 

5 each AOB_ELEMENT is given in the time search table. By 
referring to the TMSRT_entries, a playback apparatus can 
perform a forward or backward search where, for example, 
intermittent bursts of music are played back by repeatedly 
playing back 240 milliseconds of audio data and then skipping 

10 two seconds of audio data in the desired direction. 

{3-3_10-7} AOB_BLOCK 

This completes the explanation of an AOB_ELEMENT . The 
following describes the concept of the AOB_BLOCKs shown 
15 on the third level of the data construction of an AOB file 
given in FIG. 10. 

Each "AOB_BLOCK" is composed of valid AOB_ELEMENTs . 
Only one AOB_BLOCK exists in each AOB_FILE. While an 
AOB_ELEMENT has a playback period of around two seconds, 
20 an AOB_BLOCK has a maximum playback period of 8.4 minutes. 
The 8.4 minute limitation is imposed to restrict the size 
of the time search table to 504 bytes or less. 

{3-3_10-8} Restriction of the Time Search Table 

25 The following describes in detail why the size of the 
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time search table is restricted by limiting the playback 
period. 

When a playback apparatus performs a forward or 
backward search^ the playback apparatus skips the reading 
5 of two seconds of audio data before playing back 240 
milliseconds. When skipping two seconds of data, the 
playback apparatus could in theory refer to the data lengths 
shown in the ADTS headers of AOB_FRAMEs, though this would 
mean that the playback apparatus would have to consecutively 

10 detect 100 (2 seconds/20 milliseconds) AOB_FRZ\MEs just to 
skip two seconds of audio data. This would amount to an 
excessive processing load for the playback apparatus. 

To reduce the processing load of a playback apparatus, 
the read addresses for data at two-second intervals can 

15 be written into a time search table that is then referred 
to by the playback apparatus when performing a forward or 
backward search. By writing information that enables read 
addresses that are two or four seconds ahead or behind to 
be found quickly into the time search table ( such information 

20 being the data sizes of AOB_ELEMENTs) , a playback apparatus 
will only need to refer to this information when performing 
a forward or backward search. The data size of audio data 
with a playback period of two seconds will depend on the 
bitrate used when playing back the audio data. As stated 

25 earlier, a bitrate in the range of 16Kbps to 144Kbps is 
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used, so that the amount of data played back in two seconds 
will be in a range from 4KB (=1 6Kbps x 2/8) to 36KB (=144Kbps 
X2/8) . Since the amount of data played back in two seconds 
will be in a range from 4KB to 36KB, the data length of 

5 each entry in the time search table for writing the data 
length of audio data needs to be two bytes (=16 bits) long. 
This is because a 16-bit value is capable of expressing 
a number in the range 0-64KB. 

On the other hand, if the total data size of the time 

10 search table needs to be restricted to 504 bytes (this being 
the data size of the TKTMSRT described later) , for example, 
the maximum number of entries in the time search table can 
be calculated as 504/2=252. 

Since an entry is provided every two seconds, the 

15 playback time corresponding to this maximum of 252 entries 
is 504 seconds (=2s*252) , or, in other words, 8 minutes 
and 24 seconds (=8.4 minutes) . This means that setting the 
maximum playback period for an AOB__BLOCK at 8.4 minutes 
limits the data size of the time search table to 504 bytes. 

20 

{3-3__10-9} Regarding AOBs 

This concludes the description of AOB_BLOCKs. The 
following describes AOBs. 

The AOBs shown on the second level of FIG . 10 are regions 
25 that have invalid areas at either end. Only one AOB is 
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present in each AOB file. 

The invalid areas are regions that are read and written 
along with the AOB_BLOCKs and are stored in the same clusters 
as the AOB_BLOCKs . The start and end position of the 
5 AOB_BLOCKs within an AOB are shown by BITs included in the 
navigation data. These BITs are described in detail later 
in this specification. 

This completes the explanation of what data is stored 
in an AOB file . The following describes what kind of content 
10 is played back when the eight AOBs and AOB_BLOCKs shown 
in the AOB file in FIG. 9 are successively read. 

{3-3_10"10_16) 

FIG. 16 shows the playback content when the AOBs and 
15 AOB_BLOCKs in this AOB file are successively read . The first 
level in FIG. 16 shows the eight AOB files in the user region, 
while the second level shows the eight AOBs recorded in 
these AOB files . The third level shows the eight AOB_BLOCKs 
included in these AOBs. 
20 The fifth level shows the titles of five contents 

composed by these AOB files . In this example, the "contents" 
are the five songs SongA, SongB, SongC, SongD, and SongE, 
while the "title" is a music album composed of these five 
songs. The broken lines ASl, ASl, AS3, . . . AS7, and 
25 ASS show the correspondence between the AOB BLOCKS and the 
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parts into which the album is divided, so that the fourth 
level in FIG. 16 shows the units used to divide the music 
album shown on the fifth level. 

By referring to the broken lines, it can be seen that 

5 the AOB_BLOCK included in A0B#1 is a song (SongA) with a 
playback period of 6.1 minutes. The AOB__BLOCK included in 
A0B#2 is a song (SongB) with a playback period of 3 . 3 minutes . 
The AOB_BLOCK included in A0B#3 is a song (SongC) with a 
playback period of 5.5 minutes. In this way, "AOBOOl.SAl" 

10 to "AOB003.SA1" each correspond to a different song. The 
sixth level of FIG. 16 is a track sequence composed of tracks 
TrackA to TrackE. These tracks TrackA-TrackE correspond 
to the five songs SongA, SongB, SongC, SongD, and SongE, 
and are each treated as a separate playback unit. 

15 On the other hand, A0B#4 has a playback period of 8.4 

minutes and is the first (or "head") part of the song SongD 
that has a playback period of 30 . 6 minutes . The AOB_BLOCKs 
included in A0B#5 and A0B#6 are middle parts of the song 
SongD and also have playback periods of 8 . 4 minutes . The 

20 AOB_BLOCK included in A0B#7 is the end part of the song 
SongD and has a playback period of 5.4 minutes. In this 
way, a song that has a total playback period of 30. 6 minutes 
is divided into (8.4+8.4+8.4+ 5.4-minute) parts that 
are each included in a different AOB. As can be seen from 

25 FIG. 16, every song included in an AOB file is subjected 
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to a maximum playback period of 8.4 minutes. 

This explanation clearly shows that limiting the 
playback periods of AOBs as described above restricts the 
data size of the time search table corresponding to each 
5 AOB. The following describes the navigation data included 
in each time search table. 
{3-3_8A,B-2} 

The navigation data is composed of the two files 
"SD_Audio. PLM" and "SD_Audio. TKM" mentioned earlier. The 
10 file "SD_Audio.PLM" includes the PlaylistManager, while 
the file "SD_Audio.TKM" includes the TrackManager . 

As mentioned as part of the explanation of the 
presentation data, a plurality of AOB files store encoded 
AOBs, though no other information, such as the playback 
15 period of the AOBs, the names of the songs represented by 
the AOBs , or credits for the songwriter ( s ) , is given . While 
a plurality of AOBs are recorded in a plurality of AOB files, 
no indication as to the playback order of the AOBs is provided . 
To inform a playback apparatus of such information, the 
20 TrackManager and PlaylistManager are provided. 

The TrackManager shows the correspondence between the 
AOBs recorded in AOB files and tracks, and includes a 
plurality of pieces of track management information that 
each give a variety of information, such as the playback 
25 period of AOBs and the song names and songwriters of the 
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various AOBs. 

In this specification, the term "track" refers to a 
meaningful playback unit for users, so that when copyrighted 
music is stored on a flash memory card 31, each song is 
5 a separate track. Conversely, when an "audio book" (i.e., 
copyrighted literature stored as recorded audio) is recorded 
on a flash memory card 31, each chapter or paragraph can 
be set as a separate track. The TrackManager is provided 
to manage a plurality of AOBs recorded in a plurality of 
10 AOB files as a group of tracks. 

A Playlist sets the playback order of a plurality of 
tracks. A plurality of Playlists can be included in the 
PlaylistManager . 

The following describes the TrackManager with 
15 reference to the drawings. 

{17-1^18} Detailed Composition 

of the PlaylistManager and TrackManager 

FIG. 17 shows the detailed composition of the 
20 PlaylistManager and TrackManager in this embodiment as a 
hierarchy. FIG. 18 shows the sizes of the PlaylistManager 
and the TrackManager. The right side of FIG. 17 shows the 
items on the left side in more detail, with the broken lines 
indicating which items are being shown in more detail. 
25 As shown in FIG. 17, the TrackManager is composed of 
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the Track Information (TKI) #1, #2, #3, #4 • . . #n, as 
shown by the broken line hi. These TKIs are information 
for managing the AOBs recorded in AOB files as tracks, and 
each correspond to a different AOB file. From FIG. 17, it 

5 can be seen that each TKI is composed of 

Track_General_Inf ormation (TKGI) , Track_Text_Inf ormation 
(TKTXTI_DA) in which text information exclusive to a track 
can be written, and a Track_Time_Search_Table (TKTMSRT) 
that serves as a time search table. 

10 From FIG. 18, it can be seen that each TKI has a fixed 

size of 1,024 bytes, which means that total size of the 
TKGI and the TKTXTI^DA is fixed at 512 bytes due to the 
size of the TKTMSRT being fixed at 512 bytes. In the 
TrackManager, a total of 999 TKIs can be set. 

15 As shown by the broken line h3, the TKTMSRT is composed 

of a TMSRT_Header and TMSRT_entries #1, #2, #3 ... #n. 

{17-2_^19} Correspondence of TKI with AOB files and AOBs 

20 FIG. 19 shows how the TKIs shown in FIG. 17 correspond 

to the AOB files and AOBs shown in FIG. 16. The boxes on 
the first level in FIG. 19 show a sequence of tracks composed 
of tracks TrackA to TrackE, the large frame on the second 
level shows the TrackManager, while the third and fourth 

25 levels show the eight AOB files given in FIG. 16. The eight 
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AOB files are recorded in the eight AOBs shown in FIG. 16, 
and compose a music album including tracks TrackA, TrackB, 
TrackC, TrackD, andTrackE. The second level shows the eight 
TKIs- The numbers "1", "2", "3", "4" assigned to each TKI 
5 are the serial numbers used to identify each TKI, with each 
TKI corresponding to the AOB file that has been given the 
same serial number 001,002,003,004,005 .... 

With this in mind, it can be seen from FIG. 19 that 
TKI#1 corresponds to the file "AOBOOl.SAl", that TKI#2 
10 corresponds to the file "AOB002 .SAl", TKI#3 corresponds 
to the file "AOB003 .SAl", and TKI#4 corresponds to the file 
"AOB004 .SAl" . The correspondence between TKIs and 
AOB_FRAMEs is shown by the arrows TAl, TA2, TA3, TA4 . . . 
in FIG. 19. 

15 In this way, each TKI corresponds to a different AOB 

recorded in an AOB file and gives detailed information that 
applies only to the corresponding AOB. 

{17-3_20} Data Composition of a TKTMSRT 

20 The following describes the information that applies 

to single AOBs recorded in AOB files, starting with the 
TKTMSRT. FIG. 20 shows the data composition of the TKTMSRT 
in detail. 

The right side of FIG. 20 shows the detailed data 
25 composition of the time search table header (TMSRT Header) . 
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In FIG. 20, the TMSRT_Header has a data size of eight bytes, 
and is made up of three fields. The first two bytes are 
a TMSRT_ID, the next two bytes are reserved, and the final 
four bytes are a Total TMSRT_entry_Nuinber . 
5 A unique ID for identifying the TMSRT is recorded in 

the "TMSRT_ID" . The total number of TMSRT_entries in the 
present TMSRT is recorded in the "Total TMSRT_entry Number" . 

{17-3_21-1} Specific Example of the TKTMSRT 

10 The following describes a TKTMSRT in detail. FIG. 

21 shows one example of a TKTMSRT. The left side of FIG. 
21 shows an AOB, while the right side shows the corresponding 
TKTMSRT. The AOB on the left side of FIG. 21 is composed 
of a plurality of AOB_ELEMENTs numbered #1, #2, #3 ... 

15 #n that occupy the regions numbered ARl, AR2, AR3 . . . 
ARn to the right. 

The numbers such as "0", "32000", "64200", "97000", 
"1203400", and "1240000" show the relative addresses of 
areas ARl, AR2, AR3, ARn-1, ARn occupied by the AOB_ELEMENTs 

20 with respect to the start of the AOB_BLOCK. As examples, 
A0B_ELEMENT#2 is recorded at a position that is at a distance 
"32000" from the start of the AOB_BLOCK, while A0B_ELEMENT#3 
is recorded at a position that is at a distance "64200" 
from the start of the AOB_BLOCK and AOB_ELEMENT#n-l is 

25 recorded at a position that is at a distance "1203400" from 
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the start of the AOB_BLOCK. 

It should be noted that the distance between each 
occupied region and the start of the AOB_BLOCK is not a 
multiple of a certain value, meaning that the regions 

5 occupied by AOB_ELEMENTs are not of the same size . The reason 
the occupied regions have different sizes is that the varying 
amounts of data are used to encode each AOB_FRAME. 

Since the size of the region occupied by each 
AOB_ELEMENT differs, it is necessary to inform a playback 

10 apparatus in advance of the position of each AOB_ELEMENT 
in an AOBwhen performing a jump to the start of an AOB_ELEMENT . 
For this purpose, a plurality of TMSRT_entries are given 
in the TKTMSRT, The arrows RTl, RT2, RT3 . . . RTn-1, 
RTn show the correspondence between the regions ARl, AR2, 

15 AR3 . . . ARn-1, ARn occupied by each AOB_ELEMENT and 
TMSRT_entry#l,TMSRT_entry#2,TMSRT_entry#3 . . . 
TMSRT_entry#n-l, TMSRT_entry#n. In other words, the size 
of the region ARl occupied by A0B_ELEMENT#1 is written in 
the TMSRT_entry#l, while the sizes of the regions AR2 and 

20 AR3 occupied by A0B_ELEMENT#2 and A0B_ELEMENT#3 are written 
in the TMSRT_entries #2 and #3. 

Since the occupied area ARl takes up the region from 
the start of the AOB to the start of the A0B_ELEMENT#2 "32000" , 
the size "32000" (=32000-0) is written in the TMSRT_entry#l . 

25 The occupied area AR2 takes up the region from the start 

50 



wo 00/74061 



PCT/JPOO/03300 



Of the A0B_ELEMENT#2 "32000" to the start of the 
A0B_ELEMENT#3 "64200", so that the size "32200" 
(=64200-32000) is written in the TMSRT_entry#2 . The 
occupied area AR3 takes up the region from the start of 

5 the A0B_ELEMENT#3 "64200" to the start of the A0B_ELEMENT#4 
"97000", so that the size "32800" (=97000-64200) is written 
in the TMSRT_entry#3 . In the same way, the occupied area 
ARn-1 takes up the region from the start of the 
AOB_ELEMENT#n-l "1203400" to the start of the AOB_ELEMENT#n 

10 "1240000", the size "36600" (=1240000-1203400) is written 
in the TMSRT_entry#n-l. 

{17-3_21-2} How the TKTMSRT is read 

In this way, the data sizes of AOB_ELEMENTs are written 
15 in a time search table. However, since the data length of 
each AOB_BLOCK is restricted to a maximum of 8 • 4 minutes, 
the total number of AOB_ELEMENTs included in a single AOB 
is limited to a predetermined number ("252" as shown in 
FIG. 20) or less. Since the number of AOB_ELEMENTs is 
20 restricted, the number of TMSRT_entries corresponding to 
AOB_ELEMENTs is also restricted, which restricts the size 
of the TKTMSRT including these TMSRT_entries to within a 
predetermined size. Since the size of the TKTMSRT is 
restricted, a playback apparatus can read and use TKIs in 
25 the following way. 
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The playback apparatus reads a certain AOB and on 
commencing playback of the AOB, reads the corresponding 
TKI and stores it in a memory. This corresponding TKI is 
kept in the memory while the playback of this AOB continues . 
5 Once the playback of the AOB ends, the following AOB is 
read, and when the playback of this AOB commences, the 
playback apparatus overwrites the TKI corresponding to 
this following AOB into the memory in place of the old TKI. 
This next TKI is kept in the memory while the playback of 

10 this following AOB continues. 

By reading and storing TKIs in this way, the necessary 
capacity of the memory in the playback apparatus can be 
minimized while still enabling special playback functions 
such as forward and backward search to be realized. While 

15 the present embodiment describes the case where the data 
length from the first address of an AOB_ELEMENT to the first 
address of the next AOB_ELEMENT is written in the TMSRT_entry , 
relative addresses from the start of the AOB_BLOCK to the 
first addresses of AOB_ELEMENTs may be written in there 

20 instead. 



{17-3_21-3) Specifying a Cluster 

Including an AOB^ELEMENT 

The following describes how an AOB_ELEMENT may be read 
25 using the TKTMSRT. The TKTMSRT includes the size of each 
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AOB_ELEMENT, so that when AOB_ELEMENT#y, which is the y^^ 
AOB_ELEMENT from the start of an AOS, is to be read^ the 
cluster u that satisfies Equation 1 given below is calculated, 
and data positioned with the offset v from the start of 
5 the cluster u is read. 

Equation 1 

Cluster u == (Total of the TMSRT_entries f rom A0B_ELEMENT#1 
to AOB_ELEMENT#y-l + DATA_Offset) / Cluster size 

10 

Offset V = (Total of the TMSRT_entries from A0B_ELEMENT#1 
to AOB_ELEMENT#y-l + DATA_Offset) mod Cluster size 

where c=a mod b indicates that c is the remainder 
produced when a is divided by b 

15 

The DATA_Of f set is written in the BIT and is described 
later in this specification. 

{17-4} TKTXIJJA 

20 This completes the explanation of the time search table 

(TKTMSRT) . The following describes the 

Track_Text_Inf ormation Data Area (TKTXI_DA) recorded in the 
upper part of the TKTMSRT. 

The Track_Text_Information Data Area (TKTXTI_DA) is 
25 used to store text information showing the artist name, 
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album name, mixer, producer, and other such information. 
This area is provided even when such text information does 
not exist. 

5 {17-5} TKGI 

The following describes the TKGI recorded in the upper 
part of the TKTXI_DA. In FIG. 11, several sets of 
information shown as the identifier "TKI_ID" of the TKI, 
the TKI number "TKIN", the TKI size "TKI_SZ", a link pointer 
10 to the next TKI "TKI_LNK_PTR" , block attributes 

"TKI_BLK_ATR" , a playback period "TKI_PB_TM", the audio 
attributes "TKI_AOB_ATR" , an "ISRC", and block information 
"BIT". Note that only some of this information has been 
shown in FIG. 17 to simplify the representation. 

15 

{17-5_22-l} TKGI 

The following describes the composition of a TKGI in 
detail, with reference to FIG. 22. The difference between 
FIG. 17 and FIG. 22 is that the data composition of the 
20 TKGI that was shown in FIG. 17 is arranged on the left side 
of this drawing, and that the bit compositions of 
"TKI_BLK_ATR" , "TKI_AOB_ATR" and "ISRC" are clearly shown. 

{17-5_22-2} TKI_ID 

25 A unique ID for a TKI is written in the "TKI_ID" . In 
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the present embodiment/ a two-byte "A4" code is used. 

{17-5_22-3) TKIN 

A TKI number in the range of 1 to 999 is written in 
5 the "TKIN". Note that the TKIN of each TKI is unique. In 
the present embodiment, the position of each TKI in the 
TrackManager is used as the TKIN. This means that "1" is 
written as the TKI number of TKI#1, "2" is written as the 
TKI number of TKI#2, and "3" is written as the TKI number 
10 of TKI#3. 

{ 17-5__22-4 ) TKI_SZ 

The data size of the TKI in byte units is written in 
the "TKI_SZ". In FIG. 22, 1,024 bytes is given as the data 
15 size of the TKI so that each TKI in the present embodiment 
is 1,024 bytes long. 

{17-5_22-5} TKI_LNK_PTR 

The TKIN of the TKI to which the present TKI is linked 
20 is written in the "TKI_LNK_PTR" . The following describes 
such links between TKIs . 

When a track is composed of a plurality of AOBs which 
are recorded in a plurality of AOB files, these AOB files 
will be managed as a single track by linking the plurality 
25 of TKIs that correspond to these AOB files. To link a 
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plurality of TKIs, it is necessary to show the TKI of the 
AOB file that follows after the AOB file of the present 
TKI. Accordingly, the TKIN of the TKI that follows the 
present TKI is written in TKI_LNK__PTR. 

5 

{17-5__22-6_19} TKI_LNK_PTR 

The following describes the settings made for the 
TKI_LNK_PTR in the eight TKIs shown in FIG. 19. The track 
10 information numbered #1 to #3 and #8 each correspond to 
separate tracks, so no information is set in their 
TKI_LNK_PTR. The track information 

TKI#4,TKI#5,TKI#6,TKI#7 correspond to the four AOB files 
that compose TrackD, so that the next track information 

15 is indicated in the TKI_LNK_PTR of these TKIs. As shown 
by the arrows TL4, TL5, and TL6 in FIG. 19, "TKI#5" is set 
in the TKI_LNK_PTR of TKI#4 , "TKI#6" is set in the TKI_LNK_PTR 
of TKI#5, and "TKI#7" is set in the TKI_LNK_PTR of TKI#6. 
As a result, a playback apparatus can refer to the 

20 TKI_LNK_PTRs given in the TKIs corresponding to these four 
AOB files and so find out that the four TKIs TKI#4 to TKI#7 
and the four AOB files "AOB004.SA1" to "AOB007.SA1" compose 
a single track, TrackD. 

25 
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{ 17-5_22-7 } TKI_BLKjATR 

The attributes of present TKI are written in the 
"TKI_BLK_ATR" . In FIG. 22, the information shown within 
the broken lines extending form the TKI_BLK_ATR shows the 
5 bit composition of the TKI_BLK_ATR. In FIG. 22, the 
TKI_BLK_ATR is shown as being 16 bits long, with the bits 
from b3 to bl5 being reserved for future use. The three 
bits from bit b2 to bO are used to show the attributes of 
the TKI. 

10 When one TKI corresponds to a complete track, the value 

"00b" is written in the TKI_BLK_ATR (this setting is 
hereafter referred to as "Track") • When several TKIs 
correspond to the same track, the value "001b" is written 
intheTKI_BLK_ATRof the first TKI (this setting is hereafter 

15 referred to as "Head_of_Track") , the value "010b" is written 
in the TKI_BLK_ATRs of the TKIs that correspond to AOBs 
in themiddle of the track (this setting is hereafter referred 
to as "Midpoint_of_Track") , and the value "011b" is written 
in the TKI_BLK_ATR of the TKI that corresponds to the AOB 

20 at the end of the track (this setting is hereafter referred 
to as "End_of_Track" ) . When a TKI is unused but a TKI region 
exists, which is to say, when there is a deleted TKI, the 
value "100b" is written in the TKI_BLK_ATR (this setting 
is hereafter referred to as "Unused") . When a TKI is unused 

25 and no TKI region exists, the value "101b" is written in 
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the TKI_BLK_ATR. 

{17-5_22-8_19) Exanqple Setting of the TKI_BLK_ATR 

The following describes the settings of the 
5 TKI_BLK_ATR for each TKI in the example shown in FIG. 19. 

By referring to the TKI_BLK_ATR of each TKI, it can 
be seen that the four pairs TKI#1 ("AOBOOl .SAl") , TKI#2 
("AOB002.SA1") , TKI#3 ( "AOB003 . SAl" ) , and TKI #8 
("AOB008 .SAl") each correspond to separate tracks since 

10 the TKI_BLK_ATR of each of TKI#1, TKI#2, TKI#3, and TKI#8 
is set as "Track". 

The TLK_BLK_ATR of TKI#4 is set at "Head_of_Track" , 
the TLK_BLK_ATR of TKI#7 is set at "End_of_Track" , and the 
TLK_BLK_ATRof TKI#5 andTKI#6 is set at "Midpoint _of_Track" . 

15 This means that the AOB file ("AOB004 .SAl") corresponding 
to TKI#4 is the start of a track, the AOB files ("AOB005. SAl") 
and ("AOB006.SA1") corresponding to TKI#5 and TKI#6 are 
midpoints of the track, and the AOB file ("AOB007 .SAl") 
corresponding to TKI#7 is the end of a track. 

20 By classifying the combinations of TKI and 

corresponding AOB file in accordance with the settings of 
the TKI_BLK_ATR in the TKI , it can be seen that the combination 
of TKI#1 and "AOBOOl. SAl" composes a first track (TrackA) . 
Likewise, the combination of TKI#2 and "AOB002.SA1" composes 

25 a second track (TrackB) and the combination of TKI#3 and 
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"AOB003.SA1" composes a third track (TrackC) . The 
combination of TKI#4 and "AOB004.SA1" composes the first 
part of the fourth track (TrackD) , the combinations of TKI#5 
with "AOB005.SA1" and TKI#6 with "AOB006.SA1" compose 
5 central parts of TrackD, and the combination of TKI#7 and 
"AOB007.SA1" composes the end part of TrackD. Finally, the 
combination of TKI#8 and "AOB008 • SAl" composes a fifth track 
(TrackE) . 

10 {17-5_22-9) TKI_PB_TM 

The playback period of the track (song) composed of 
the AOB recorded in the AOB file corresponding to a TKI 
is written in the "TKI_PB_TM" in the TKI. 

When a track is composed of a plurality of TKIs, the 
15 entire playback period of the track is written in the 
TKI_PB_TM of the first TKI corresponding to the track, while 
the playback period of the corresponding AOB is written 
into the second and following TKIs for the track. 

20 {17-5_22-10} TKI_AOB_ATR 

The encoding conditions used when producing an AOB, 
which is to say information such as (1) the sampling frequency 
at which the AOB recorded in the corresponding AOB file 
was sampled, (2) the transfer bitrate, and (3) the number 
25 of channels, is written in the "TKI AOB ATR" in a TKI. The 
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bit composition of the TKI_AOB_ATR is shown within the broken 
lines that extend from the "TKI_AOB_ATR" in FIG. 22. 

In FIG. 22, the TKI_AOB_ATR is composed of 32 bits, 
with the coding mode being written in the four-bit field 
5 from bit bl6 to bit bl9. When the AOS is encoded according 
toMPEG-2AAC (withADTS header) , the value "0000b" is written 
into this field, while when the AOB is encoded according 
to MPEG-layer 3 (MP3) , the value "0001b" is written. When 
the AOB is encoded according to Windows Media Audio (WMA) , 
10 the value "0010b" is written in this field. 

The bitrate used when encoding the AOB is written in 
the eight-bit field between bit bl5 and bit b8 . When the 
AOB is encoded according to MPEG-2 AAC (with ADTS header) , 
a value between "16" and "72" is written into this field, 
15 while when the AOB is encoded according to MPEGl-layer 3 
(MP3) , a value between "16" and "96" is written. When the 
AOB is encoded according to MPEGl-layer 3 (MP3) LSF, a value 
between "16" and "80" is written into this field, while 
when the AOB is encoded according to Windows Media Audio 
2a (WMA), a value between "8" and "16" is written. 

The sampling frequency used when encoding the AOB is 
written in the four-bit field between bit b7 and bit b4. 
When the sampling frequency is 48kHz, the value "0000b" 
is written in this field. When the sampling frequency is 
25 4 4 .1kHz, the value is "0001b", when the sampling frequency 
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is 32kHz, the value "0010b", when the sampling frequency 
is 24kHz, the value "0011b", when the sampling frequency 
is 22.05kH2, the value "0100b", and when the sampling 
frequency is 16kHz, the value "0101b". 
5 The number of channels is written in the three-bit 

field from bit b3 to bit bl. When one channel (i.e., 
monaural) is used, the value "000b" is written in this field, 
while when two channels (i.e., stereo) is used, the value 
"001b" is written in this field. 
10 The twelve-bit field from bit b31 to bit 20 is reserved 

for future use, as is the bit bO. 

{17-5_22-ll} ISRC 

An ISRC (International Standard Recording Code) is 
15 written in the TKGI. In FIG. 22, the broken lines extending 
from the "ISRC" box show the content of the ISRC. As shown 
in the drawing, the ISRC is composed of ten bytes, with 
a Recording-item code (#12) being written into the four-bit 
field between bit b4 and bit b7. A Recording 
20 code/Recording-item code (#11) is written in the four-bit 
field between bit b8 and bit bll. 

A Recording Code (ISRC#10, #9, #8) is written in the 
twelve-bit field between bit bl2 and bit b23. A 
Year-of -Recording code (ISRC#6, #7) is written in the 
25 eight-bit field b24 and bit bSl. 
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The First Owner Code (ISRC #3, #4, #5) is written in 
the six-bit field between bit b32 and bit b37, the six-bit 
field between bit b40 and bit b45, and the six-bit field 
between bit b48 and bit b53. The Country Code (ISRC #1^ 
5 #2, #3) is written in the six-bit field between bit b56 
and bit b61 and the six-bit field between bit b64 and bit 
b69, A one-bit Validity flag is written in a one-bit field 
composed of bit b79. A detailed description of ISRC can 
be found in ISO3901:1986 "Documentation-International 
10 Standard Recording Code (ISRC)", 

{17-5_22-12_23A-l} BIT 

The "Block Information Table (BIT)" is a table for 
managing an AOB_BLOCK, and has the detailed composition 

15 shown in FIGS. 23A and 23B. 

As shown in FIG. 23A, a BIT is composed of a DATA_OFFSET 
field that occupies a region from the 60th byte to the 63rd 
byte, an SZ_DATA field that occupies a region from the 64th 
byte to the 67th byte, a TMSRTE_Ns field that occupies a 

20 region from the 68 th byte to the 71st byte, an FNs_lst_TMSRTE 
field that occupies a region from the 72nd byte to the 73rd 
byte, an FNs_Last_TMSRTE that occupies a region from the 
74th byte to the 75th byte, an FNs_Middle_TMSRTE field that 
occupies a region from the 7 6th byte to the 77th byte, and 

25 a TIME_LENGTH field that occupies a region from the 78th 
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byte to the 79th byte. 

Each of these fields is described in detail below. 

{17-5_22-12_23A-2) DATA_Offset 

5 The relative address of the start of an AOB_BLOCK from 

the boundary between clusters is written in the 
"DATA_OFFSET" as a value given in byte units . This expresses 
the size of an invalid area between an AOB and the AOB_BLOCK. 
As one example, when a user records a radio broadcast on 
10 a flash memory card 31 as AOBs and wishes to delete an intro 
part of a track over which a DJ has. spoken, the DATA_OFFSET 
in the BIT can be set to have the track played back without 
the part including the DJ's voice. 

15 {17-5_22-12_23A-3) SZ_DATA 

The data length of an AOB_BLOCK expressed in byte units 
is written in "SZ_DATA". By subtracting a value produced 
by adding the SZ_DATA to the DATA_Of f set from the file size 
(an integer multiple of the cluster size) , the size of the 
20 invalid area that follows the AOB_BLOCK can be found. 

{17-5_22-12_23A-4) TMSRTEJ»s 

The total number of TMSRT_Entries included in an 
AOB_BLOCK is written in "TMSRTE_Ns". 

25 
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{ 17-5_22-12_23A-5 } "ENs__lst__TMSRTE" , 

"ENs_Last_TMSRTE" , "PNs__Middle_TMSRTE" 

The number of AOB_FRAMEs included in the AOB_ELEMENT 
positioned at the start of a present AOB_BLOCK is written 
5 in "FNs_lst_TMSRTE". 

The number of AOB_FRAMEs included in the AOB_ELEMENT 
positioned at the end of the present AOB_BLOCK is written 
in "FNs_Last_TMSRTE" . 

The number of AOB_FRAMEs included in each AOB_ELEMENT 
10 apart from those at the start and the end of the present 
AOB_BLOCK, which is to say AOB_ELEMENTs in the middle of 
the AOB_BLOCK, is written in "FNs_Middle_TMSRTE" . 

The playback period of an AOB_ELEMENT is written in 
the format shown in FIG. 23C in the "TIME_LENGTH" field 
15 to an accuracy in the order of milliseconds. As shown in 
FIG. 23C, the "TIME_LENGTH" field is 1 6-bit s long. When 
the encoding method used in MPEG-ACC or MPEG-Layer 3, the 
playback period of an AOB_ELEMENT is two seconds, so that 
the value "2000" is written in the "TIME_LENGTH" field. 

20 

{17-5_22-13_23B) 

FIG. 23B shows the number of AOB_FRAMEs indicated by 
"FNs_Middle_TMRTE" . In the same way as FIG. 14, FIG. 23B 
shows the relationship between the sampling_f requency and 
25 the number of AOB_FRAMEs included in an AOB_ELEMENT in the 
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middle of an AOB_BLOCK. 

The relationship between the sampling_frequency and 
the number of frames included in the AOB_ELEMENT shown in 
FIG. 23B is the same as that shown in FIG. 14, which is 

5 to say, the number of frames in an AOB_ELEMENT depends on 
the sampling frequency used. The number of frames written 
in "FNs_lst_TMSRTE" and "FNs_Last_TMSRTE" will 
fundamentally be the same as the number written in 
"FNs_Middle_TMSRTE", though when an invalid area is present 

10 in the AOB_ELEMENTs at the start and/or end of an AOB_BL0CK, 
the values given in "FNs_lst_TMSRTE" and/or 
"FNs_Last_TMSRTE" will differ from the value in 
"FNs_Middle_TMSRTE" . 

15 {17-5__22-14__24) Exanple of a Stored AOB_ELEMENT 

FIG. 24 shows the clusters 007 to OOE that store the 
AOB composed of A0B_ELEMENT#1 to A0B_ELEMENT#4 . The 
following describes the settings in the BIT when an AOB 
is stored as shown in FIG. 24. A0B_ELEMENT#1 to 

20 A0B_ELEMENT#4 that are stored in cluster 007 to cluster 
OOE are indicated in FIG. 24 by the triangular flags, with 
TMSRT_entries being set in the TKI for each of A0B_ELEMENT#1 
to A0B_ELEMENT#4 . 

In this example, the first part of A0B_ELEMENT#1 at 

25 the start of the AOB is stored in cluster 007, while the 
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last part of A0B_ELEMENT#4 at the end of the AOB is stored 
in cluster OOE. The AOB_ELEMENTs #1 to #4 occupy the region 
between mdO in cluster .007 to md4 in cluster OOE. As shown 
by arrow sdl in FIG. 24, the SZ_DATA in the BIT indicates 

5 that AOB_ELEMENTs #1 to #4 occupy a region from the start 
of cluster 007 to the end of cluster OOE, and so does not 
indicate that there are the invalid areas udO and udl in 
clusters 007 and OOE that are not occupied by an AOB_ELEMENT . 
On the other hand, the AOB also includes the parts 

10 udO and udl that are present in clusters 007 and OOE but 
are not occupied by A0B_ELEMENT#1 or A0B_ELEMENT#4 . The 
DATA_Offset given in the BIT gives the length of the 
unoccupied region udO, which is to say, a position value 
for the start of the A0B_ELEMENT#1 relative to the start 

15 of cluster 007. 

In FIG. 24, the A0B_ELEMENT#1 occupies a region from 
mdO in cluster 007 to mdl in cluster 008. 

This A0B_ELEMENT#1 does not occupy all of cluster 008, 
with the remaining part of the cluster being occupied by 

20 A0B_ELEMENT#2 . AOB_ELEMENT# 4 occupies a region f rom md3 
midway through cluster OOC to md4 midway through cluster 
OOE. In this way, AOB_ELEMENTs may be stored across cluster 
boundaries, or in other words, AOB_ELEMENTs can be recorded 
without regard for the boundaries between clusters. The 

25 "FNs_lst_TMSRTE" in the BIT shows the number of frames in 
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A0B_ELEMENT#1 that is located in clusters 007 and 008, while 
the "FNs_Last_TMSRTE" in the BIT shows the number of frames 
in A0B_ELEMENT#4 that is located in clusters OOC to OOE. 
In this way, AOB_ELEMENTs can be freely positioned 
5 without regard for the boundaries between clusters . The 
BIT provides information showing the offset from a cluster 
boundary to an AOB_ELEMENT and the number of frames in each 
AOB_ELEMENT . 

10 {17-5_22-14_25} Use of the Number of Frames given in each 
AOB_ELEMENT (part 1) 

The following describes how the number of frames in 
each AOB_ELEMENT given in the BIT is used. This number of 
frames given in the BIT is used when forward or backward 
15 search is performed. As mentioned earlier, such operations 
play back 240 milliseconds of data after first skipping 
data with a playback period of two seconds. 

FIG. 25 shows how AOB_FRAME#x+l, which should be played 
back next, is set when performing forward search starting 
20 from an AOB_FRAME#x in an AOB_ELEMENT#y in an AOB. 

FIG. 25 shows the case when a user selects forward 
search during the playback of AOB_FRAME#x included in 
AOB_ELEMENT#y. In FIG. 25, "t" represents the intermittent 
playback period (here, 240 milliseconds) , "f (t)" shows the 
25 number of frames that correspond to this intermittent 
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playback period, "skip_time" shows the length of the period 
that shouldbe skippedbetween intermittent playback periods 
(here, two seconds), "f (skip_time) " shows the number of 
frames that correspond to this skip time. Intermittent 
5 playback is achieved by repeating the three procedures (1) , 
(2) , and (3) described below. 

(1) The playback apparatus refers to the TMSRT_entry in 
the TKTMSRT and jumps to the start of the flag symbol 

10 (AOB_ELEMENT) . 

(2) The playback apparatus performs playback for 240 
milliseconds . 

15 (3) The playback apparatus jumps to the start of the next 
flag symbol (AOB_ELEMENT) . 

The AOB_FRAME#x+l that exists 2s+240ms from the 
AOB_FRAME#x included in the AOB_ELEMENT#y will definitely 
be present in the AOB_ELEMENT#y+l . When specifying the 

20 AOB_FRAME#x+l that is 2s+240ms from the AOB_FRAME#x, the 
first address of the next AOB_ELEMENT#y+l can be immediately 
calculated by reading a TMSRT_entry from the TKTMSRT, though 
a playback apparatus cannot know the number of AOB_FRAMEs 
from the start address of the AOB_ELEMENT#y+l to the 

25 AOB_FRAME#x+l from the TMSRT_entry alone. 
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To calculate this number of AOB_FRAMEs, it is necessary 
to subtract the total number of frames included in the 
AOB_ELEMENT#y from the total of (1) the number#x showing 
the position of the AOB_FRAME#x relative to the start of 
5 the AOB_ELEMENT#y, (2) f(t) and (3) f (skip_time) • To 
simplify the calculation of the relative frame position 
of AOB_FRAME#x+l in AOB_ELEMENT#y+l, the "FNs_lst_TMSRTE" , 
"FNs_Middle_TMSRTE", and "FNs_Last_TMSRTE" for each 
AOB_ELEMENT are written in the BIT, as mentioned above. 

10 

{17*-5_22-15_26A} Use of the Number of Frames given in each 
AOB_ELEMENT (part 2) 

The number of frames written in the BIT is also used 
when the playback apparatus performs a time search function 

15 where playback starts at a point indicated using a time 
code. In FIG. 26A, shows how a playback apparatus can 
specify the AOB_ELEMENT and AOB_FRAME corresponding to the 
playback start time indicated by the user. When playback 
is to commence from a time indicated by the user, the indicated 

20 time (in seconds) is set in the Jmp_Entry f ield, and playback 
should begin from an AOB_ELEMENT#y and an AOB_FRAME position 
X that satisfy Equation 2 given below. 

Equation 2 

25 Jmp_Entry (sec) = (FNs_lst_TMSRTE + FNs_middle_TMSRTE*y+ 
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x) *20msec 

Since the "FNs_lst_TMSRTE" and "FNs_Middle_TMSRTE" 
are provided in the BIT, these can be substituted into 
5 Equation 2 to calculate the AOB_ELEMENT#y and AOB_FRAME#x. 
Having done this, a playback apparatus can refer to the 
TKTMSRT of the AOB, calculate the first address of the 
A0B_ELEMENT#y+2 (which is the (y+2)^^ AOB^ELEMENT in this 
AOB) , and start the search for AOB_FRAME#x from this first 

10 address. On finding the x^^ AOB_FRAME, the playback 

apparatus starts the playback from this frame . In this way, 
the playback apparatus can start the playback of data from 
the time indicated by Jmp_Entry {in seconds) . 

In this way, a playback apparatus does not have to 

15 search for the ADTS header parts of AOB_FRAMEs, and only 
needs to perform the search in AOB_ELEMENTs that are given 
in the TMSRT_entries in the TKTMSRT. This means that the 
playback apparatus can find a playback position 
corresponding to an indicated playback time at high speed. 

20 In the same way, when the Jmp_Entry is set and the 

time search function is used on a track that is composed 
of a plurality of AOBs, the playback apparatus only needs 
to calculate an AOB_ELEMENT#y and AOB_FRAME#x that satisfy 
Equation 3 below. 

25 
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Equation 3 

Jnip_Entry (in seconds) = 

Playback period from A0B#1 to AOB#n + 
(FNs_lst_TMSRTE (#n+l) +FNs_middle_TMSRTE (#n+l) *y+x) *20in 
5 sec 

The total playback period of the AOBs from A0B#1 to 
AOB#n is as follows. 

Total Playback Period from A0B#1 to AOB#n = 
10 ["FNS_lst_TMSRTE" (#1) +"FNs_Middle_TMSRTE" (#1) * (Nu 

mber of TMSRT_entries (#1) -2) + "FNs_Last_TMSRTE" (#1) + 

"FNs_lst_TMSRTE" (#2) + ("FNs_Middle_TMSRTE" (#2) * Number 
Of TMSRT_entries (#2) -2) + "FNs_Last_TMSRTE" (#2) + 
"FNs_lst_TMSRTE" (#3) + ("FNs_Middle_TMSRTE" (#3) * Number 
15 of TMSRT_entries (#3) -2) +"FNs_Last_TMSRTE" (#3) . . . 

+ "FNs_lst_TMSRTE" (#n) + ( "FNs_Middle_TMSRTE" (#n) * 
Number of TMSRT_entries (#n)-2) + "FNs_Last_TMSRTE" (#n) ] 

*20msec 

Having calculated an AOB#n, an AOB_ELEMENT#y, and 
20 AOB_FRAME#x that satisfy Equation 3, the playback apparatus 
refers to the TKTMSRT corresponding to the AOB#n+l, searches 
for the x^** AOB_FRAME from the address at which the (y+2)^'* 
AOB_ELEMENT (i.e., A0B_ELEMENT#y+2) is positioned, and 
starts the playback from this x^^ AOB_FRAME. 

25 
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{17-5_22-16_27A,B) Deletion of an AOB Pile and a TKI 

This completes the explanation of all of the 
information included in the TKI. The following describes 
how the TKI is updated in the following four cases • In the 
5 first case (easel) , a track is deleted. In the second case 
(case2) a track is deleted and a new track is recorded. 
In the third case (case3) two out of a plurality of tracks 
are selected and combined into a single track. Finally^ 
in the fourth case (case4) , one track is divided to produce 

10 two tracks. 

The following describes easel where a track is deleted. 
FIGS. 27Aand 27B show the partial deletion of a track. 
The example in FIGS. 27A and 27B corresponds to the 
TrackManager shown in FIG. 19, and assumes that the user 

15 has indicated the partial deletion of Track B. The AOB 
corresponding to TrackB is recorded in "AOB002 . SAl" , which 
is associated with TKI#2. This means that the deletion of 
"AOB002.SA1" is accompanied by the setting of "Unused" into 
the TKI_BLK_ATR of TKI#2. This state where "AOB002.SA1" 

20 has been deleted and "Unused" has been set into the 
TKI_BLK_ATR of TKI#2 is shown in FIG. 27B. Since 
"AOB002.SA1" has been deleted, the region that was formerly 
occupied by "AOB002.SA1" is freed to become an unused region. 
As mentioned above, the other change is that "Unused" is 

25 set in the TKI BLK ATR of TKI#2. 
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{17-5_22-17_28A,B} Assignment of TKIs when a new AOB is 
recorded 

The following describes case2 where a new track is 

5 recorded after the deletion of a track. 

FIG. 28A shows the TrackManager after the deletion 
of tracks has been performed several times. As shown in 
FIG. 28A, if the tracks corresponding to TKI#2, TKI#4, TKI#7, 
and TKI#8 have been deleted, then "Unused" is set in the 

10 TKI_BLK__ATR of these TKI. While AOB files are deleted in 
the same way as conventional data files, the TrackManager 
is updated by merely setting "Unused" in the TKI_BLK_ATR 
of the corresponding TKI. These means that TKIs whose 
TKI_BLK_ATRs are set at "Unused" can appear at different 

15 places in the TrackManager. 

FIG. 28B shows how a new TKI and AOB file are written 
when a TKI whose TKI_BLK_ATR is "Unused" is present in the 
TrackManager. Like in FIG. 28A, the TKI#2, TKI#4, TKI#5, 
TKI#7, and TKI#8 in FIG. 28B are set as "Unused". 

20 In FIG. 28B, the new track to be written is composed 

of four AOBs. The unused TKIs used to record these AOBs 
are determined according to the DPL_TK_SRPs or can be freely 
chosen. In the present example, the unused TKIs numbered 
TKI#2, TKI#4, TKI#7, and TKI#8 are used to record the TKIs 

25 for the new track. 
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Since these four AOBs compose one track, 
"Head_of_Track" is set in the TKI_BLK_ATR of TKI#2, 
"Middle_of_Track" is set in the TKI_BLK_ATR of TKI#4 and 
TKI#7, and "End_of_Track" is set in the TKI_BLK_ATRof TKI#8 . 

5 The TKI_LNK_PTR in each of the four TKIs, TKI#2, TKI#4, 
TKI#7, and TKI#8, used to compose the new TrackD is set 
so as to show the TKI forming the next part of TrackD, so 
that as shown by the arrows TL2, TL4, and TL7, TKI#4 is 
set in the TKI_LNK_PTR of TKI#2, TKI#7 is set in the 

10 TKI_LNK_PTR of TKI#4, and TKI#8 is set in the TKI_LNK_PTR 
of TKI#7. 

After this, the files "AOB002 .SAl", "AOB004 .SAl", 
"AOB007.SA1", and "AOB008.SA1" having the same numbers as 
TKI#2,TKI#4,TKI#7,TKI#8 are produced, and the four AOBs 
15 composing TrackD are stored in these four files . 

By appropriately setting the TKI_LNK_PTRs and 
TKI_BLK_ATRs, this fourth track TrackD can be managed using 
TKI#2, TKI#4, TKI#7, and TKI#8. 

As described above, when a new track is written onto 
20 the flash memory card 31, TKis in the TrackManager that 
are set as "Unused" are assigned as the TKIs to be used 
for tracks that are to be newly recorded. 

25 
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{17-5_22-18_29A,B} Setting of TKI when Combining Two 
Tracks 

The following describes the updating of the TKI when 
combining tracks (case3) . 
5 FIGS. 29A and 29B show how the TKIs are set when two 

tracks are combined to produce a new track. The example 
in FIG. 29A uses the same TrackManager as FIG. 19 and shows 
the case when the user performs an editing operation to 
combine TrackC and TrackE into a single track. 

10 In this case, the AOBs that correspond to TrackC and 

TrackE are recorded in the AOB files "AOB003.SA1" and 
"AOB008.SA1" which correspond to TKI#3 and TKI#8, so that 
the TKI_BLK_ATRs of TKI#3 and TKI#8 are rewritten. FIG. 
29B shows the TKI_BLK_ATR of these TKIs after rewriting. 

15 In FIG. 29A, the TKI_BLK_ATRs of TKI#3 and TKI#8 is written 
as "Track", but in FIG. 29B the TKI_BLK_ATR of TKI#3 is 
rewritten to "Head_of_Track" and the TKI__BLK_ATR of TKI #8 
is rewritten as "End_of_Track" . By rewriting the 
TKI_BLK_ATRs in this way, the AOB files "AOB003.SA1" and 

20 "AOB008.SA1" which correspond to TKI#3 and TKI#8 end up 
being treated as parts of a single track, the new TrackC. 
This operation is accompanied by the TKI_LNK_PTR of TKI#3 
being rewritten to indicate TKI#8. 

It should be particularly noted here that while the 

25 TKI_BLK_ATRs in the TKI are rewritten, no processing is 
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performed to physically combine the AOB files "AOB003.SA1" 
and "AOB008.SA1". This is because AOB files are each 
encrypted using different FileKeys^ so that when combining 
AOB files, it would be necessary to perform two processes 

5 for each AOB file to first decrypt the encrypted AOB file 
and then to re-encrypt the result, resulting in an excessive 
processing load. Also, an AOB file combined in this way 
would be encrypted using a single FileKey, which would make 
the combined track less secure that the tracks used to produce 

10 it. 

The TKI is originally designed so as to suppress the 
size of the TKTMSRT, so that the physical combining of AOB 
files by an editing operation would also carry the risk 
of the TKI becoming too large. 
15 For the reasons given above, editing operations that 

combine tracks leave the AOB files in their encrypted state 
and are achieved by merely changing the attributes given 
by the TKI_BLK_ATRs . 

20 {17-5_22-18_29A,B-l_30, 31) Conditions That Should be 
Satisfied When Combining Tracks 

The combining of tracks is performed by changing the 
TKI_BLK_ATR attributes as described above, but the AOBs 
that are included in the combined tracks should satisfy 
25 the conditions given below. 
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A first condition is that the AOB that is to compose 
a latter part of a new track needs to have the same audio 
attributes (audio coding mode, bitrate, sampling frequency, 
number of channels, etc.) as the AOB that is to compose 
5 the first part of the new track. If an AOB has different 
audio attributes to the preceding or succeeding AOB, the 
playback apparatus will have to reset the operation of the 
decoder, which makes seamless (i.e., uninterrupted) 
playback of consecutive AOBs difficult. 

10 The second condition is that in the track produced 

by the combining, three or more AOBs made up of only 
AOB_ELEMENTs whose number of AOB_FRAMEs is below the 
required number for an "FNs_Middle_TMSRTE" cannot be linked. 
AOBs are classified into two types depending on whether 

15 at least one AOB_ELEMENT includes a same number of AOB_FRi\MEs 
as the number of frames stipulated for an ' 
"FNs_Middle_TMSRTE". The Typel AOB includes at least one 
AOB_ELEMENT having this number of AOB_FRAMEs, while the 
Type2 AOB includes no AOB_ELEMENT having this number of 

20 AOB_FRAMEs . 

In other words, AOB_ELEMENTs in a Type2 AOB have fewer 
AOB_FRAMEs than "FNs_Middle_TMSRTE", and the second 
condition stipulates that three Type2 AOBs cannot be linked 
together. 

25 The reason for the second condition is as follows. 
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When the playback apparatus reads AOBs successively, it 
is preferable for a sufficient number of AbB_FRAMEs to 
accumulate in the buffer of the playback apparatus, though 
this cannot be achieved when there are consecutive Type2 

5 AOBs. In such case, an underflow is likely to occur in the 
buffer of the playback apparatus, so that uninterrupted 
playback by the playback apparatus can no longer be 
guaranteed. Therefore, in order to avoid such underflows, 
the second condition stipulating that three or more Type2 

10 AOBs cannot be linked continuously is used. 

FIG. 30A shows a Typel AOB, while FIG. 30B shows two 
examples of Type2 AOBs. In FIG. 30B, both AOBs are composed 
of less than two AOB_ELEMENTs, with none of the AOB_ELEMENTs 
including a number of AOB_FRAMEs that is set for an 

15 "FNs_Middle_TMSRTE". Since the absence of an AOB_ELEMENT 
with the number of AOB_FRAMEs set for an "FNs_Middle_TMSRTE" 
is the condition by which an AOB is classified as a Type2 
AOB, this means that all of the AOBs shown in this drawing 
are classified as Type2 AOBs. 

20 In FIG. 31A, a combining of Typel+Type2+Type2+Typel 

AOBs into a single track is shown. As this combining does 
not involve the linking of three Type2 AOBs, these AOBs 
may be linked to form a single track. 

FIG. 31B shows the linking of Typel+Type2+Type2+ 

25 Type2+Typel AOBs into a single track. This combining would 
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result in there being three consecutive Type2 AOBs, and 
so is prohibited. 

5 {17-5_22-18_29A,B-l_32 } Combining of Tracks with respect 
to coznbinations of Typel and Type2 AOBS 

In the combining of AOBs into a single track shown 
in FIG. 31A, if the last AOB in the first track is a Typel 
AOB, the combining can be performed regardless of whether 

10 the first part of this track is a Typel AOB or a Type2 AOB. 
FIG. 32A shows the case where the last AOB in the first 
track is a Typel AOB and the first AOB in the next track 
is also a Typel AOB. FIG. 32B shows the case where the last 
AOB in the first track is a Typel AOB and the first AOB 

15 in the next track is a Type2 AOB. As the second condition 
is satisfied in both of these cases, the illustrated tracks 
can be combined into a single track. 

When the last AOB in the first track is a Type2 AOB 
and the preceding AOB in the first track is a Type 1 AOB, 

20 this first track can be combined with a following track 
that starts with a Typel AOB regardless of whether the first 
AOB in the first track is a Typel AOB or a Type2 AOB. 

FIG- 32C shows the case where the first track ends 
with a Typel AOB and a Type2 AOB in that order and the second 

25 track starts with a Typel AOB . FIG . 32D shows the case where 
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the first track ends with a Typel AOB and a Type2 AOB in 
that order and the second track starts with a Type2 AOB 
and a Typel AOB in that order. As the second condition is 
satisfied in both of these cases, the illustrated tracks 
5 can be combined into a single track. 

When the first track ends with a Type2 AOB and the 
immediately preceding AOB is also a Type2 AOB, this first 
track can be combined with a following track that starts 
with a Typel AOB. FIG. 32E shows the case where the first 

10 track ends with two Type2 AOBs and the second track starts 
with a Typel AOB. As the second condition is satisfied 
in this case, the illustrated tracks can be combined into 
a single track. In this way, when two tracks are to be 
combined, an investigation is performed to see whether the 

15 two tracks satisfy the first and second conditions and the 
two tracks are only combined if they are judged to satisfy 
these conditions. 

The following describes the updating of the TKI for 
case4 where a track is divided. 

20 

{17-5_22-19_33A,B) Settings for the TKI When a Track is 
Divided 

FIGS. 33A and 33B show examples of when a single track 
is to be divided to produce two new tracks. For these 
25 examples, the content of the TrackManager is the same as 
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in FIG. 27, with the user being assumed to have performed 
an editing operation that divides TrackC into two new tracks , 
TrackC and TrackF. When TrackC is to be divided into a new 
TrackC and TrackF, the AOB file "AOB002.SA1" is generated 
5 corresponding to TrackF. FIG. 33A shows that TKI#2 is set 
as "Unused", with this TKI#2 being assigned to the newly 
generated AOB file "AOB002.SA1". 

{17-5_22-19_33A,B-l_34A,B> Updating of the Directory 
10 Entries and the FAT Values 

When the AOB file "AOB003.SA1" is divided to produce 
"AOB002.SA1" the directory entries and FAT values have to 
be updated. This updating is explained below. FIG.'34A 
shows how the SD-Audio Directory Entry in the SD-Audio 

15 Directory to which the AOB file "AOB003.SA1" belongs is 
written before the file is divided. 

The AOB file "AOB003.SA1" is divided into a plurality 
of parts that are stored in clusters 007, 008, 009, OOA . . . 
OOD, OOE. In this case, the first cluster number for the 

20 AOB file "AOB003 . SAl" given in the directory entry is written 
as "007". The values (008), (009), (OOA) . . . (OOD), (OOE) 
are also written in the FAT values 007, 008, 009, OOA . . . 
OOD corresponding to the clusters 007, 008, 009, OOA . . . 
OOD. 

25 When the AOB file "AOB003.SA1" is divided so that its 
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latter part becomes the new AOB file "AOB002,SA1", a 
"filename", a "filename extension" and a "number of first 
clusters in file" for the new AOB file "AOB002.SA1" are 
added to the SD-Audio directory entry. FIG. 34B shows how 
5 the SD-Audio Directory Entry in the SD-Audio Directory to 
which the AOB file "AOB003.SA1" belongs is written after 
the AOB file "AOB003.SA1" has been divided. 

In FIG. 34B, the cluster OOF stores a copy of cluster 
GOB that includes the boundary indicated by the user when 

10 dividing the file. The parts of the AOB file "AOB002.SA1" 
that follow the part included in the cluster OOB are stored 
in the clusters OOC, OOD, OOE as before. Since the first 
part of the AOB file "AOB002.SA1" is stored in the cluster 
OOF and the remaining parts are stored in the clusters OOC, 

15 OOD, OOE, "OOF" is written into the "number of first cluster 
in file" for the new AOB file "AOB002 . SAl", while (OOC), 
(OOD) , (OOE) are written into the FAT values OOF, OOC, OOD, 
OOE corresponding to the clusters OOF, OOC, OOD, and OOE. 

20 {17-5_22-19_33A,B-2__35A,B) 

Setting of the Information Fields in the TKI 

The following describes how the information fields 
in the TKI are set for the AOB file "AOB002.SA1" once this 
file has been obtained by updating the directory entries 
25 and the FAT values. When generating a TKI for a divided 
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track, there are two kinds of information fields in the 
TKI. These are (1) information that can be copied from the 
original TKI and (2) information obtained by updating the 
information in the original TKI. The TKTXTI_DA and ISRC 
5 are the former type, while the BIT, the TKTMSRT and other 
information fields are the latter type. Since both types 
of information exist, the present embodiment generates a 
TKI for a divided track by copying the original TKI to produce 
a template for the new TKI, and then dividing/updating the 

10 TKTMSRT and BIT in this template and updating the remaining 
information fields . 

FIG. 35A shows the case where an AOB_FRAME in an AOB 
is divided. The first level in FIG. 35A shows the four 
AOB_ELEMENTs , A0B_ELEMENT#1, A0B_ELEMENT#2 , A0B_ELEMENT#3, 

15 and A0B_ELEMENT#4 . The data lengths of these AOB_ELEMENTs 
are set in the TKTMSRT as the four TMSRT_entries #1, #2, 
#3, and #4. If the boundary bdl for the division is set 
in A0B_ELEMENT#2 in FIG. 35A, A0B_ELEMENT#2 is divided into 
a first region (1) made up of the frames located before 

20 the boundary bdl and a second region (2) composed of the 
frames located after the boundary bdl. FIG. 35B shows the 
two AOBs A0B#1 and A0B#2 obtained by dividing the AOB midway 
though A0B_ELEMENT#2 . 

25 
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{17-5_22-19_33A,B-3_36} Setting of the BIT 

FIG. 36 shows how the BIT is set when an AOB is divided 
as shown in FIG. 35. The AOB shown in FIG. 35 is divided 
at the boundary bdl. The A0B#1 produced by this division 

5 includes the two A0B_ELEMENTs A0B_ELEMENT#1 and 

A0B_ELEMENT#2, while the other A0B#2 produced by this 
division includes the three AOB_ELEMENTs, A0B_ELEMENT#1, 
A0B_ELEMENT#2, and A0B_ELEMENT#3 . 

In FIG. 36, these AOB_ELEMENTs have also been given 

10 the triangular flags to shows the settings of the 

TMSRT_entries included in the TKIs corresponding to these 
AOBs. The explanation will first focus on A0B#1 which is 
obtainedby this division. A0B_ELEMENT#1 andA0B_ELEMENT#2 
that are included in A0B#1 occupy cluster 007 to cluster 

15 OOA, so that A0B#1 is handled as being the composite of 
cluster 007 to cluster OOA. A0B_ELEMENT#2 in A0B#1 has a 
data length that ends not at the end of cluster OOA, but 
at the boundary bdl that is present within cluster OOA, 
so that the SZ_DATA for A0B#1 is given as the amount of 

20 data from the region mdO to the boundary bdl in cluster 
OOA. The "FNs_lst_TMSRTE" for A0B#1 is the same as before 
division, while the "FNs_Last_TMSRTE" for A0B#1 differs 
from the value used before division in that it now indicates 
the number of frames from the start of A0B_ELEMENT#2 before 

25 division to the boundary bdl. 
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The following describes A0B#2 which is obtained by 
this division. A0B_ELEMENT#1, A0B_ELEMENT#2, and 
A0B_ELEMENT#3 that are included in A0B#2 occupy cluster 
OOB to cluster 007. Cluster OOF includes a copy of the 
5 content of cluster OOA. The reason cluster OOF stores a 
copy of cluster OOA is that cluster OOA is occupied by 
A0B_ELEMENT#2 in A0B#1, so that it is necessary to assign 
a different cluster to A0B_ELEMENT#1 in A0B#2 . 

A0B_ELEMENT#1 in A0B#2 has a data length that starts 
10 not at the beginning of cluster OOF, but at the boundary 
bdl that is present within cluster OOF, so that the SZ_DATA 
for A0B#2 is given as the amount of data from the start 
of cluster OOB to a point midway through cluster OOE plus 
the data length of the part of cluster OOF occupied by 

15 A0B_ELEMENT#1. 

The part of A0B_ELEMENT#2 in A0B#1 that is included 
in the copy of cluster OOA stored in cluster OOF needs to 
be excluded from A0B#2, so that the DATA_Offset field in 
the BIT of A0B#2 is set at the size of the part of A0B_ELEMENT#2 

20 in A0B#1 included in cluster OOF. 

As can be seen from FIG. 36, the division of the AOB 
result in only the AOB_ELEMENT that includes the boundary 
for the division being divided into two and in the other 
AOB_ELEMENTs positioned before and after the divided 

25 AOB_ELEMENT remaining unchanged. As a result, the 
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"FN_Last_TMSRTE" of A0B#2 is set at the same value for the 
"A0B_ELEMENT#4" before the division, and the 
"FNs_lst_TMSRTE" of A0B#2 is set at A0B_ELEMENT#1 of A0B#2, 
which is to say, the number of frames included in the part 
5 that follows the boundary once A0B_ELEMENT#2 has been 
divided . 

{17-5__22-19__33A,B-4_37} Setting of the BIT 

FIG. 37 shows a more specific example of changes in 

10 the BITS as a result of the division of a track. The left 
side of FIG. 37 shows an example of the settings of the 
BIT before division. In this BIT, the Data_Offset is set 
as "X", the SZ_DATA is set at "52428", and the TMSRTE_Ns 
is set at "n". The FNs_lst_TMSRTE is set at "80 frames", 

15 the FNs_Middle_TMSRTE is set at "94 frames", and the 
FNs_Last_TMSRTE is set at "50 frames". 

The right side of FIG. 37 shows the settings of two 
BITS produced by the division of a track. When the AOB 
corresponding to the BIT on the left side of FIG. 37 is 

20 divided as shown in FIG. 35A, the Data_Offset in the BIT 
of the first track produced by the division is set at "X" 
like the track before division", the "SZ_DATA" is updated 
to the data length "Q" from the start to the division point 
Q, and the TMSRTE_Ns is set at "k" which shows the number 

25 of TMSRT_entries from the first TMSRT_entry to the k'^'' 
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TMSRT_entry . The FNs_lst_TMSRTE and FNs_Midclle_TMSRTE are 
respectively set at "80" and "94" frames in the same way 
as the BIT before division, but since the final AOB_ELEMENT 
in the AOB of the first track produced by the divis ion includes 
5 "p" AOB_FRAMES, the FNs_Last_TMSRTE is set at "p frames." 

In the BIT of the second track produced by the division, 
the "Data_Offset" is set at "R", the "SZ_DATA" is set at 
(original SZ#DATA "52428"-data length up to division point 
Q),and the TMSRTE_Ns is set at "n-k+1" produced by adding 
10 one (for the kth TMSRT_entry that is newly added as a result 
of the division) to the number of TMSRT_entries from the 
k" TMSRT_entry to the n^^ TMSRT_entry. 

The FNs__Middle_TMSRTE and FNs_Last_TMSRTE are set at 
the same values as the BIT before division, which is to 
15 say, "94 frames" and "50 frames" respectively. 

The first AOB_ELEMENT in the AOB of this second track 
includes "94-p" AOB_FRAMEs, so that "94-p" is set in the 
FNs_lst_TMSRTE of the BIT corresponding to this track. 

20 {17-5_22-19_33A,B-5_38} Setting of the BIT 

FIG. 38 shows the TKTMSRT after division. The 
following explains the settings of the TMSRT first. The 
TMSRT of the first track includes the TMSRT_entries from 
the first TMSRT_entry of the AOB before division to the 
25 kth TMSRT_entry, which is to say, the TMSRT_entries #1 to 
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#k. 

It should be noted here that the AOB_ELEMENT#k that 
includes the boundary for the division only includes region 
(1) , so that the k^^ TMSRT_entry only includes a data size 

5 corresponding to this region (1) • The TMSRT of the second 
track includes the TMSRT_entries from the kth TMSRT_entry 
of the AOB before division to the n^^ TMSRT_entry, which 
is to say, the TMSRT_entries #k to #n. It should be noted 
here that the AOB_ELEMENT#k that includes the boundary for 

10 the division only includes region (2) , so that the k^*^ 
TMSRT_entry only includes a data size corresponding to this 
region (2) . 

The copying of the TKI is accompanied by the division 
and updating of the TKTMSRT and the BIT , and once the remaining 

15 information has been updated, the TKIs for the new tracks 
produced by the division will be complete. In the same way 
as when combining tracks, the AOB files are not decrypted, 
so that two tracks can be produced by dividing an AOB file 
in its encrypted state. Since the division of an AOB file 

20 does not involve decryption and re-encryption, the 

processing load of dividing a track can be suppressed. This 
means that tracks can be edited even by a playback apparatus 
with limited processing power. 

This completes the explanation of the TKI. The 

25 following describes the Playlists. 
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{ 17- 6 } PlaylistManager 

As shown by the broken lines h5 in FIG. 17, the 
PlaylistManager shown is made up of 
PlaylistManager_Information (PLMGI) for managing the 

5 Playlists stored in the flash memory card 31, 

Default_Playlist_Information (DPLI) for managing all of 
the track stored in the flash memory card 31, and 
Playlistlnformation (PLI) #1, #2, #3, #4 . . . #m. Each 
PLI is information for a user-defined Playlist. As shown 

10 by the broken lines h6, the DPLI is composed of 
Def ault_Playlis t_General_Inf ormation ( DPLGI ) and 
Default_Playlist_Track_Search_Pointers (DPL_TK_SRP) #1, 
#2, #3, #4 . . . #m. As shown by the broken lines h7, each 
PLI is composed of Playlist_General_Information (PLGI), 

15 andPlaylist_Track_Search_Pointers (PL_TK_SRP) #1, #2, #3, 
#4 . . . #m. 

The DPLI referred to here differs from each PLI in 
the following way. While the DPLI has to indicate all of 
the tracks stored in the flash memory card 52, a PLI does 

20 not have this restriction and can indicate any number of 
the tracks. This opens up various possibilities for the 
user. As representative examples, the user can generate 
Playlist_Information indicating only his (her) favorite 
tracks and store this Playlist_Information in the flash 

25 memory card 31, or can have a playback apparatus 

89 



wo 00/74061 



PCT/JPOO/03300 



automatically generate Playlist_Information that only 
indicates tracks of a certain genre, out of a plurality 
of tracks stored in the flash memory card 31, and store 
the resulting Playlist Information in the flash memory card 
5 31. 

{17-7_18) Number of Playlists stnd Their Data Sizes 

As shown in FIG. 18, a maximum of 99 Playlists can 
be stored on one flash memory card 31. The combined data 

10 • size of the PlaylistManager_Information (PLMGI) and the 
Default Playlist Information (DPLI) is also fixed at 2,560 
bytes. Each PLI has a fixed length of 512 bytes. The 
"DPL_TK_SRP" included in the Default Playlist Information 
includes a "DPL_TK_ATR" and a "DPL_TKIN" . On the other hand, 

15 the "PL_TK_SRP" field included in a PLI includes only a 
"PL_TK_SRP". The format of the DPL_TK_ATR, DPL_TKIN, and 
PL_TKIN fields is shown in FIG. 39. 

{17-8__39-l} Fonoat of DPL_TK_SRP 

20 FIG. 39A shows the format of the DPL_TK_SRP. In FIG. 

39A, the DPL_TKIN is written in the 0th to 9th bits in the 
DPL_TK_SRP, while the DPL_TK_ATR is written in the 13th 
to 15th bits. The 10th to 12th bits in the DPL_TK_SRP are 
reserved for future use. 

25 The TKI number is written in the DPL_TKIN that occupies 
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the 0th to 9th bits in the DPL_TK_SRP. This enables a TKI 
to be specified. 

{17-9_39B) Format of the PL_TK_SRP 

5 FIG. 39B Shows the format of the PL_TK_SRP. This is 

a ten-bit field in which PL_TKIN, which is to say, a TKI 
number, is written. 

{17-8_39A-2} Coii?)OSition of DPL_TK_ATR 

10 The broken lines h51 and h52 that extend from the 

DPL_TK_ATR in FIG. 39A show an example setting of the 
DPL_TK_ATR. As can be seen from this drawing, the DPL_TK_ATR 
is set for a DPL_TK_SRP in the same way as TKI_BLK_ATR is 
set for a TKI, which is to say, the DPL_TK_ATR is set at 

15 one of "Track", "Head_of_Track" 

"Midpoint_of_Track", and "End_of_Track" . 

In more detail, when the TKI indicated by the TKIN 
is used and an Audio Object (AOB) corresponding to one 
complete track is recorded in the AOB file corresponding 

20 to the indicated TKI (i.e., when the TKI_BLK_ATR of the 
TKI is "Track") , the value "00b" is set in the "DPL_TK_ATR" . 

When the TKI indicated by the TKIN is used and an Audio 
Object (AOB) corresponding to only the start of a track 
is recorded in the AOB file corresponding to the indicated 

25 TKI (i.e., when the TKI_BLK_ATR of the TKI is 
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"Head_of_Track") , the value "001b" is set in the 
"DPL_TK_ATR". When the TKI indicated by the TKIN is used 
and an Audio Object (AOB) corresponding to a midway part 
track is recorded in the AOB file corresponding to the 
5 indicated TKI (i.e., when the TKI_BLK_ATR of the TKI is 
"Midpoint_of_Track") , the value "010b" is set in the 
"DPL_TK_ATR". When the TKI indicated by the TKIN is used 
and an Audio Object (AOB) corresponding to an end part of 
a track is recorded in the AOB file corresponding to the 

10 indicated TKI (i.e., when the TKI_BLK_ATR of the TKI is 
"End_of_Track") , the value "011b" is set in the 
"DPL_TK_ATR" . 

Conversely, when the TKI indicatedby the TKIN is unused 
and the TKI region is merely established, which corresponds 

15 to when a TKI has been deleted (i.e., when the TKI_BLK_ATR 
of the TKI is "Unused"), the value "100b" is set in the 
DPL_TK_ATR. 

When the TKI indicated by the TKIN is unused and no 
TKI region has been established, which is to say, when a 
20 TKI is in an initial state, the value "101b" is set in the 
"DPL_TK_ATR" . 

Since the number of a TKI is written in the DPL_TKIN, 
it is clear which of the plurality of TKI corresponds to 
each DPL_TK_SRP. The position of the DPL_TK_SRP in the 
25 Default_Playlist_Information shows when the AOB 
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corresponding to the TKI that in turn corresponds to the 
DPL_TK_SRP will be played back, i.e., the ordinal position 
of the AOB in the Default_Playlist . As a result, the order 
of the DPL_TK_SRP items in the Def ault_Playlist denotes 
5 the order in which a plurality of tracks will be played, 
or in other words, determines the playback order of tracks. 

{17-9_40-l} Interrelationship Between the 
Default^Playlist^Inforxnation, TKI, and AOB files 

10 FIG. 40 shows the interrelationship between the 

Def ault_Playlist_Inf ormation, the TKI, and the AOB files. 
The second, third, and fourth levels in this drawing are 
the same as the first, second, and third levels in FIG. 
19, and so show a TrackManager including eight TKI and eight 

15 AOB files. FIG. 40 differs from FIG. 19 in that a box showing 
the Def ault_Playlist_Inf ormation is given on the first level . 
The eight small divisions shown in this box show the eight 
DPL_TK_SRP included in the Def ault_Playlist_Information. 
The upper part of each division shows the DPL_TK_ATR, while 

20 the lower part shows the DPL_TKIN. 

As shown by the arrows DTI, DT2, DT3, DT4 ... in 
FIG. 40, DPL_TK_SRP#1 and TKI#1 are related, as are 
DPL_TK_SRP#2 and TKI#2, DPL_TK_SRP#3 and TKI#3, and 
DPL_TK_SRP#4 and TKI #4. 

25 Looking at the DPL_TK_ATR fields in the DPL_TK_SRP, 
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it can be seen that "Track" has been set for each of 
DPL_TK_SRP#1, DPL_TK_SRP#2, DPL_TK_SRP#3, and 
DPL_TK_SRP#8 . In other words, the four combinations 
DPL_TK_SRP#1 - TKI#1 ("AOBOOl.SAl") , DPL_TK_SRP#2 - 

5 TKI#2("AOB002.SA1") , DPL_TK_SRP#3 - TKI#3 ("AOB003.SA1") , 
DPL_TK_SRP#8 - TKI#8 ("AOB008.SA1") correspond to four 
separate tracks. 

Meanwhile, none of DPL_TK_SRP#4, DPL_TK_SRP#5, 
DPL_TK_SRP#6, and DPL_TK_SRP#7 has a DPL_TK_ATR set as 

10 "Track". Instead, the DPL_tk_srp#4 of DPL_TK_ATR is set 
at "Head_of_Track", the DPL_TK_ATR of DPL_TK_SRP#7 is set 
at "End_of_Track" and the DPL_TK_ATRs of DPL_TK_SRP#5 and 
DPL_TK_SRP#6 are set at "Midpoint_of_Track" . 

This means that TKI#4 ("AOB004 .SAl") , which is related 

15 to DPL_TK_SRP#4, is the start of a track, 

TKI#5("AOB005.SA1") and TKI#6 ("AOB006 . SAl") , which are 
respectively related to DPL_TK_SRP#5 and DPL_TK_SRP# 6 , are 
middle parts of a track, and TKI#7 ("AOB007 .SAl") , which 
is related to DPL_TK_SRP#7, is the end of a track. 

20 The DPL_TK_SRP entries in the DefaultPlaylist show in 

what order the AOBs corresponding to each TKI are to be 
playedback. The DPL_TKINs of DPL_TK_SRP#1, #2, #3, #4 . . . 
#8 in the DefaultPlaylist of FIG. 40 indicate TKI#1, #2, 
#3, #4 ... #8. As shown by the arrows (1) (2) (3) (4) . . . 

25 (8) , the AOB file "AOBOOl.SAl" corresponding to TKI#1 will 
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be played back first, "AOB002.SA1" corresponding to TKI#2 
will be played back second, "AOB003.SA1" corresponding to 
TKI#3 will be played back third, and "AOB004.SA1" 
corresponding to TKI#4 will be played back fourth. 

5 

{17-10_41} Exanple Settings for the DefaultPlaylist and 
Playlist__Zn£oxinatlon 

FIG. 41 shows example settings for the 
Default_Playlist and the Playlist_Information using the 

10 same notation as FIG. 40. In FIG. 41, the box on the first 
level shows the Default_Playlist, while the three boxes 
on the second level show the PLIs. 

The small divisions in the box showing the 
Default_Playlist shows the eight DPL_TK_SRP values included 

15 in the Def ault_Playlist, while the small divisions in the 
boxes illustrating each PLI show three or four PL_TK_SRP 
values . The setting of the TKIN of each DPL_TK_SRP included 
in the Default_Playlist_Information is the same as in FIG. 
40. However, the settings of the TKIN of the PL_TK_SRP 

20 included in each PLI are completely different to those in 
the DPL_TK_SRP. 

{17-10_42} Correspondence between the DPL__TK_SRP and the 
TKI 

25 FIG. 42 shows the correspondence between the 
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DPL_TK_SRP and the TKI using the same notation as in FIG. 
40. In FIG. 42, Playlist#l is composed of PL_TK_SRP#1, #2, 
#3. Of these, #3 is written as the PL_TKIN of PL_TK_SRP#1, 
while #1 is written as the PL_TKIN of PL_TK_SRP#2 and #2 
5 as the PL_TKIN of PL_TK_SRP#3. This means that when tracks 
are played back according to Playlist#l, a plurality of 
AOBs will be played back as shown by the arrows (11) (12) 
(13) in the order A0B#3, A0B#1, A0B#2. 

Playlist#2 is composed of PL_TK_SRP#1, #2, #3. Of 

10 these, #8 is written as the PL_TKIN of PL_TK_SRP#1, while 
#3 is written as the PL_TKIN of PL_TK_SRP#2 and #1 as the 
PL_TKIN of PL_TK_SRP#3. This means that when tracks are 
played back according to Playlist#2, a plurality of AOBs 
will be played back, as shown by the arrows (21) (22) (23) 

15 in the order A0B#8, A0B#3, A0B#1, which is to say, in a 
completely different order to Playlist#l. 

Playlist#3 is composed of PL_TK_SRP#1, #2, #3, #4 . the 
PL_TKIN of these PL_TK_SRP#1 to #4 are respectively set 
as #8, #4, #3, and#l. This means that when tracks are played 

20 back according to Playlist#3, a plurality of AOBs will be 
played back as follows. First, A0B#8 that composes TrackE 
is played back as shown by the arrow (31) . Next, A0B#4, 
A0B#5, A0B#6, and A0B#7 that compose TrackD are played back 
as shown by the arrow (32) . After this, A0B#3 and A0B#1 

25 that respectively compose TrackC and TrackA are played back 
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as shown by the arrows (33) and (34) . 

Of special note here is that when a track is composed 
of a plurality of TKI, only the TKI number of the start 
of the track is written into the PL_TK_SRP entry. In more 

5 detail, while the DPL_TK_SRP values given in the 
Default_Playlist_Inforraation specifies the four TKIs 
(TKI#4,TKI#5,TKI#6,TKI#7) that compose TrackD, the 
PL_TK_SRP given in a set of Playlist_Information does not 
need to indicate all four TKIs. For this reason, 

10 PL_TK_SRP#2 in Playlist#3 only indicates TKI#4 out of TKI#4 
to TKI#7. 

On the other hand, a DPLI including a plurality of 
DK_TK_SRP has a data size that is no greater than one sector 
and is always loaded into the RAM of a playback apparatus. 

15 When tracks are played back according to a Playlist, the 
playback apparatus refers to the DK_TK_SRPs that are loaded 
into its RAM and so can search for TKIs at high speed. To 
play back TKIs (AOBs) using a PL_TK_SRP that only indicates 
the TKI number of the first TKI , a playback apparatus searches 

20 the DPL_TK_SRP loaded in its RAM based on the TKI indicated 
by the PL_TK_SRP and judges whether the current track is 
composed of a plurality of TKI. If so, the playback 
apparatus executes the appropriate procedure for playing 
back all of the corresponding TKIs (AOBs) . 

25 As described above, the Default_Playlist and a 
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plurality of PLIs are written in the Playlist_Manager . If 
different playback orders are written in the DPL_TKINs and 
PL_TKINs of the DPL_TK_SRPs and PL_TK_SRPs composing such 
playlists, it becomes possible to play back AOBs in different 
5 orders. By offering a variety of playback orders to the 
user in this way, the user can be given the impression of 
there being a number of music albums stored in the flash 
memory card 31. 

Of special note here is that the data size of the 

10 DPL_TK_SRP corresponding to an AOB file is small (at no 
more than two bytes), while the data size of the TKI 
corresponding to an AOB file is large (at up to 1, 024 bytes) . 
When reordering the TKI in the TrackManager, a large number 
of accesses need to be made to the flash memory card 31, 

15 but when the DPL_TK_SRPs are reordered in the 

Default_Playlist_Informationor aPLI, this can be performed 
with fewer accesses to the flash memory card 31. 

In view of this, when the navigation data is edited, 
the order of the DPL_TK_SRPs in the Default_Playlist is 

20 actively changed in accordance with the editing operation, 
while the order of the TKI in the TrackManager is left 
unchanged in spite of the editing operation. 

{17-9_40-2_43A,B} Reordering of the DPL_TK_SRP 

25 The following describes an editing operation that 
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changes the playback order of tracks by reordering the 
DPL_TK_SRPs in the Def ault_Playlist_Inf ormation . FIGS. 
43A and 43B show one example of the reordering of tracks. 
The settings of the DPL_TK_SRPs and TKIs in FIG. 43A are 
5 the same as in FIG. 40. 

In FIG. 40A, the DPL_TKIN in DPL_TK_SRP#3 is set at 
TKI#3, while the DPL_TKIN in DPL_TK_SRP#8 is set at TKI#8. 
The following describes the case when these DPL_TK_SRPs 
with the thick outlines in FIG. 40A are interchanged. 

10 The numbers (1) (2) (3) (4) (5) (6) (7) (8) in FIG. 43B show 

the playback order of tracks after this editing operation. 
It should be noted here that while the playback order shown 
in FIG. 43A is TrackA, TrackB, TrackC, TrackD, TrackE, in 
FIG. 43B the DPL_TKINs of DPL_TK_SRP#3 and DPL_TK_SRP#8 

15 are interchanged in the Default_Playlist_Inf ormation, so 
that the tracks will be played back in the order TrackA^ 
TrackB, TrackE, TrackD, TrackC. In this way, the playback 
order of tracks can be easily changed by changing the order 
of the DPL_TK_SRPs in the Default_Playlist_Information. 

20 While the above explanation deals with an editing 

operation that changes the order of tracks, the following 
will describe the following four operations that were 
explained with respect to the changes in the TKIs. These 
operations are a first case (easel) where a track is deleted, 

25 a second case (case2) where a new track is recorded, a third 
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case (case3) where two freely selected tracks are combined 
to produce a new track, and a fourth case (case4) where 
a track is divided to produce two new tracks . 

5 {17-9_40-3_44A,B} Deletion of a Track 

The following describes easel where a track is deleted. 
FIGS. 44A and 44B show how the Def ault^Playlist, 
TrackManager, and AOB files are updated when, out of the 
DefaultPlaylist shown in FIG. 40, DPL_TK_SRP#2 and TKI#2 

10 are deleted. In these drawings, the same part of an AOB 
is deleted as in FIG . 27 that was used to describe the deletion 
of a TKI. As a result, the second, third, and fourth levels 
in FIG. 44Aand 44B are the same as in FIG. 27 . The difference 
with FIG. 27 is that Def ault_Playlist_Inf ormation including 

15 a plurality of DPL_TK_SRPs is given on the first level, 
in the same way as FIG. 40. 

The present example deals with the case when the user 
deletes TrackB composed of DPL_TK_SRP#2-» 
TKI#2 ("AOB002.SA1") that is shown with the thick outline 

20 in FIG. 44A. In this case, DPL_TK_SRP#2 is deleted from 
Default_Playlist_Information and DPL_TK_SRP#3 to 
DPL_TK_SRP#8 are each moved up by one place in the playback 
order so as to fill the place in the order freed by the 
deletion of DPL_TK_SRP#2 . 

25 When the DPL_TK_SRPs are moved up in this way, the 
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final DPL_TK_SRP#8 is set as "Unused". On the other hand, 
the TKI corresponding to the deleted part is set as "Unused" 
as shown in FIGS. 27A and 27B without other TKIs being moved 
to fill the gap created by the deletion. Deletion of the 
TKI is also accompanied by the deletion of the AOB file 
"AOB002.SA1". 

In this way, DPL_TK_SRPs are moved up in the playback 
order but TKIs are not moved, so that in FIG. 44B only the 
DPL_TKINs in the DPL_TK_SRPs are updated . For this example , 
the DPL^TKIN in DPL_TK_SRP#2 is set SO as to indicate TKI#3 
as shown by the arrow DTll, the DPL_TKIN in DPL_TK_SRP#3 
is set so as to indicate TKI#4 as shown by the arrow DT12, 
the DPL_TKIN in DPL_TK_SRP#4 is set so as to indicate TKI#5, 
and the DPL_TKIN in DPL_TK_SRP#5 is set so as to indicate 
TKI#6. The DPL_TKIN in DPL_TK_SRP#8 that has been set at 
"Unused" is set so as to indicate TKI#2, as shown by the 
arrow DT13. 

When a track iis deleted, the DPL_TK_SRP used for 
following tracks in the playback order are moved up, while 
the TKI corresponding to the deleted track is set at "Unused" 
while remaining in its present position. In this way, an 
editing operation is not accompanied by movement of TKIs, 
which suppresses the processing load when editing tracks . 
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{17-9_40-4_45A,B) Assignment of TKIs when Recording Tracks 

The following describes case2 when a new track is 
recorded following the partial deletion of a track. FIGS. 
45A and 45B show how an operation that writes a new TKI 
5 and DPL_TK_SRP is performed when an "Unused" TKI and 
DPL_TK_SRP are present. 

These drawings are largely the same as FIGS. 28A and 
28B that were used to explain the assignment of a new TKI 
to a TKI set at "Unused" . The second, third, and fourth 
10 levels in FIGS. 45A and 45B are the same as the first three 
levels in FIGS. 28A and 28B. The difference between these 
drawings is that the first levels in FIGS. 45A and 45B show 
the Def ault_Playlist_Information composed of a plurality 
of DPL_TK_SRP. In FIG. 45A, the DPL_TK_SRP#4 to 
15 DPL_TK_SRP#8 are set as "Unused". On the other hand, in 
FIG. 28 the TKI#2, TKI#4, TKI#5, TKI#7, TKI#8 are set as 
"Unused" . 

While TKIs set at "Unused" are present here and there 
in the TrackManager, the "Unused" DPL_TK_SRPs are positioned 
20 next to one another in the Default_Playlist_Information. 
This results from the used DPL_TK_SRPs being moved up in 
the Def ault__Playlist_Inf ormation as described above, while 
no such moving up is performed for TKIs. 

The following explanation describes the case when 
25 TrackD composed of four AOBs is written. The TKIs for these 
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four AOBs are respectively written into the following 
"Unused" TKIs in the TrackManager : TKI#2; TKI#4; TKI#7; 
and TKI#8. 

The DPL_TK_SRPs for these four AOBs are written in 
5 DPL_TK_SRP#4 to DPL_TK_SRP#7 in the 

Default_Playlist_Information. Since these four AOBs 
compose a single track, the DPL_TK_ATR of DPL_TK_SRP#4 is 
set at "Head_of_Track", the DPL_TK_ATRs of DPL_TK_SRP#5 
and DPL_TK_SRP#6 are set at "Middle_of_Track", and the 
10 DPL_TK_ATR of DPL_TK_SRP#7 is set at "End_of__Track" . 

The DPL_TKIN of DPL_TK_SRP#4 is set at TKI#2, the 
DPL_TKIN of DPL_TK_SRP#5 at TKI#4, the DPL_TKIN of 
DPL_TK_SRP#6 at TKI#7, and the DPL_TKIN of DPL_TK_SRP#7 
at TKI#8. 

15 By setting the DPL_TKINs and DPL_TK_ATRs in this way, 

TKI#2, TKI#4, TKI#7 and TKI#8 are managed as the fourth 

track TrackD. 

In the above processing, a write is performed for 

"Unused" TKIs, though this has no effect on the other TKIs 
20 TKI#1, TKI#2, TKI#3, and TKI#4, as was also the case in 

FIGS. 28A and 28B. 

{17-9__40-5_46A,B} Case3: Combining Tracks 

The following describes the updating of the 
25 Default Playlist Information when tracks are combined 
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(i.e., in case3) . FIGS. 46A and 46B show one example of 
the combining of tracks . 

These drawings are largely the same as FIGS. 29A and 
29B that were used to explain the combining of TKIs. The 
5 second, third, and fourth levels in FIGS. 46A and 46B are 
the same as the first two levels in FIGS. 29A and 29B. The 
difference between these figures is that the first levels 
in FIGS. 4 6A and 4 6B show Def ault_Playlist_Inf ormation, 
in which DPL_TK_SRP#8 is set at "Unused" and is related 

10 to TKI#2 that is also set at "Unused". When an editing 
operation combining tracks is performed for AOB files and 
TKIs as shown in FIGS. 29A and 29B, the contents of 
DPL_TK_SRP#3 to DPL_TK_SRP#6 are each moved down by one 
and the content of DPL_TK_SRP#7 that is shown with the thick 

15 outline is copied into DPL_TK_SRP#3 as shown in FIGS. 46A 
and 46B. The TKIs are also updated, as shown in FIGS. 29A 
and 29B. 

{17-9_40-6_47A,B} Case4: Division of a Track 

20 The following describes the updating of the 

Default_Playlist_Information when a track is divided 
(case4) . 

FIGS. 47A and 47B show one example of the division 
of a track. These drawings are largely the same as FIGS. 
25 33A and 33B that were used to explain the division of TKIs. 

104 



wo 00/74061 



PCT/JPOO/03300 



The second and third levels in FIGS. 47A and 47B are the 
same as the first two levels in FIGS. 33A and 33B. The 
difference between these figures is that the first level 
in FIGS. 47A and 47B shows Default_Playlist_Information, 
5 in which DPL_TK_SRP#8 is set at "Unused" and is related 
to TKI#2 that is also set at "Unused". 

If, as in FIGS. 33A and 33B, the user indicates the 
division of TKI#3 ("AOB003.SA1") shown with the thick 
outline into two, the positions of DPL_TK_SRP#3 to 

10 DPL_TK_SRP#7 are each moved down by one in the order, and 
a DPL_TK_SRP set at "Unused" is moved within the 
Default_Playlist_Information to the former position of 
DPL_TK_SRP#3. 

This new DPL_TK_SRP#3 is associated with the TKI , TKI#2 , 

15 newly produced by the division. The AOB file "AOB002.SA1" 
associated with TKI#2 stores what was originally the latter 
part of the AOB file "AOB003.SA1" . DPL_TK_SRP#2 is present 
before the DPL_TK_SRP#3 that is associated with TKI#2 and 
is associated with TKI#2 and "AOB002 .SAl" . 

20 This is to say, "AOB002.SA1" and "AOB003.SA1" 

respectively store the latter and former parts of the 
original "AOB003 .SAl", with the DPL_TK_SRP#2 and 
DPL_TK_SRP#3 corresponding to these files indicating that 
these AOBs are to be played back in the order "AOB003.SA1" 

25 and "AOB002.SA1" . As a result, the latter and former parts 
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Of the original "AOB003.SA1" will be played back in the 
order former part, latter part in accordance with the 
playback order given in the DPL_TK_SRP. 

5 {17-9__40-8) Application of the Editing Processing 

By combining the above four editing processes, a user 
can perform a great variety of editing operations. When, 
for example, a recorded track has an intro over which a 
disc jockey has talked, the user can first divide the track 

10 to separate the part including the disc jockey's voice. 
The user can then delete this track to leave the part of 
the track that does not include the disc jockey. 

This completes the explanation of the navigation data . 
The following describes a playback apparatus with a suitable 

15 composition for playing back the navigation data and 
presentation data described above. 

{48-1} External J^>pearance of the Playback Apparatus 

20 FIG. 48 shows a portable playback apparatus for the 

flash memory card 31 of the present invention . The playback 
apparatus shown in FIG . 4 8 has an insertion slot for inserting 
the flash memory card 31, a key panel for receiving user 
indications for operations such as playback, forward search, 

25 backward search, fast forward, rewind, stop etc., and an 
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LCD (liquid crystal display) panel . In terms of appearance^ 
this playback apparatus resembles other kinds of portable 
music players. 

The key panel includes: 
5 a "Playlist" key that receives the selection of 

a playlist or a track; 

a "|«" key that receives a skip operation that 
moves the playback position to a start of the current track; 

a "»!" key that receives a skip operation that 
10 moves the playback position to a start of the next track; 

a "«" key and a "»" key that respectively 
receive a backward search operation and a forward search 
operation enable the user to have the playback move quickly 
through the current track; 
15 a "Display" key that receives an operation to 

have still images stored on the flash memory card 31 
displayed; 

a "Rec" key that receives a recording operation; 
an "Audio" key for receiving user selections of 
20 the sampling frequency or of stereo or monaural is to be 
used; 

a "Mark" key that receives user indications that 
mark positions in tracks; and 

an "Edit" key that receives user indications for 
25 the editing of tracks or for the input of track titles. 
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{48-2} Improvements Made in This Portable Playback Apparatus 
for the Flash Itemory Card 31 

The differences between this portable playback 
5 apparatus of the flash memory card 31 and a conventional 
portable music player lie in the following four improvements 
(1) to (4) . 

(1) A list of playlist and tracks is shown on the LCD 
panel to allow the user to indicate the 

10 Default_Playlist_lnformation, a PLI, or separate tracks. 

(2) Keys on the key panel are assigned to the playlists 
and/or tracks displayed on the LCD panel to allow the user 
to select a track or playlist that is to be played back 
or edited. 

15 (3) A time code showing a position in a track is 

displayed on the LCD panel 5 when a track is played back. 

(4) A jog dial is provided to enable the user to set 
a time code for use as playback start time when using the 
time search function or as a division boundary when dividing 

20 a track. 

(48-2_49_50) In5>rovement (2) 

The following describes improvement (2) in detail. 
FIG. 4 9 shows one example of a display screen shown on the 
25 LCD panel when the user selects a playlist, while FIGs. 
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50A to 50E show examples of the displayed content when the 
user selects a track. 

In FIG. 4 9, the ASCII character strings 
"DEFAULTPLAYLIST", "PLAYLIST#1" , "PLAYLIST#2" , 
5 "PLAYLIST#3", and "PLAYLIST#4" represent the default 
playlist and the four playlists stored in the flash memory 
card 31. 

Meanwhile, the ASCII character strings "Track#l", 
"Track#2", "Track#3", "Track#4", "Track#5" represent the 

10 five tracks that are indicated in the playback order given 
by the default playlist stored in the flash memory card 
31. In FIGS. 49 and 50A, the highlighted Playlist and track 
show the track or Playlist that is currently indicated for 
playback or editing. 

15 If the user presses the "»" key when Track#l is 

indicated for playback within a playback order given by 
the default Playlist displayed on the LCD panel, Track#2 
will be indicated for playback within the list of tracks, 
as shown in FIG. SOB. If the user presses the "»" key again, 

20 Track#3 will be indicated for playback within the list of 
tracks, as shown in FIG. 50C. 

If the user presses the "«" key when Track#3 is 
indicated for playback within a playback order given by 
the default Playlist displayed on the LCD panel, Track#2 

25 will be indicated for playback within the list of tracks, 
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as shown in FIG. 50D. As shown in FIG. 50E, if the user 
presses the "Play" key when any of the tracks is indicated, 
the playback of the indicated track will begin, while if 
the user presses the "Edit" key, the indicated track will 
5 be selected for editing. 

<48-3_51} Ixnprovement (4) 

The following describes improvement (4) in detail. 
FIGS. 51A to 51C show an example operation of the jog dial. 

10 When the user rotates the jog dial by a certain amount, 
the playback time code displayed on the LCD panel will be 
increased or decreased in accordance with this certain 
amount. The example in FIG. 51A shows the case where the 
playback time code that is initially displayed on the LCD 

15 panel is "00:00:20". 

When the user rotates the jog dial counterclockwise 
as shown in FIG. 51B, the playback time code is reduced 
to "0:00:10" in keeping with the amount by which the jog 
dial was rotated. Conversely, when the user rotates the 

20 jog dial clockwise as shown in FIG. 51C, the playback time 
code is increased to "0:00:30" in keeping with the amount 
by which the jog dial was rotated. 

By allowing the user to change the playback time code 
in this way, the playback apparatus enables the user to 

25 indicate any playback time code in a track by merely rotating 
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the jog dial. If the user then presses the "Play" key, AOBs 
will be played back starting from a position found according 
to Equation 2 and Equation 3. 

By using the j og dial during a track dividing operation, 
5 the user can make fine adjustments to the playback time 
code used as the division boundary. 

{52-1} Internal Construction of the Playback i^paratus 

The following describes the internal construction of 
10 the playback apparatus . This internal construction is shown 
in FIG. 52. 

As shown in FIG. 52, the playback apparatus includes 
a card connector 1 for connecting the playback apparatus 
to the flash memory card 31, a user interface unit 2 that 

15 is connected to the key panel and the jog dial, a R7\M 3, 
a ROM 4, a LCD panel 5 having a list frame for displaying 
a list of tracks or playlists and a playback time code frame 
for displaying a playback time code, an LCD driver 6 for 
driving the first LCD panel 5, a descrambler 7 for decrypting 

20 AOB_FRAMEs using a different FileKey for each AOB file, 
an AAC decoder 8 for referring to the ADTS of an AOB_FRAME 
descrambled by the descrambler 7 and decoding the AOB_FRAME 
to obtain PCM data, a D/A converter 9 for D/A converting 
the PCM data and outputting the resulting analog signals 

25 to a speaker or headphone jack, and a CPU 10 for performing 
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overall control over the playback apparatus. 

As can be understood from this hardware construction, 
the present playback apparatus has no special hardware 
elements for processing the TrackManager and 
5 Default_Playlist_Information. To process the 

TrackManager and Default_Playlist_Information, a DPLI 
holding area 11, a PLI storing area 12, a TKI storing area 
13, a FileKey storing area 14, and a double buffer 15 are 
provided in the RAM 3, while a playback control program 
10 and an editing control program are stored in the ROM 4. 

(52-2) DPLI Holding Area 11 

The DPLI holding area 11 is an area for continuously 
holding Default_Playlist_Information that has been read 
15 from a flash memory card 31 connected to the card connector 
1. 

{52_12} PLI Storing Area 12 

The PLI storing area 12 is an area that is reserved 
20 for storing Playlist_Information that has been selected 
for playback by the user. 

{52-3} TKI Storing Area 13 

The TKI storing area 13 is an area that is reserved 
25 for storing only the TKI corresponding to the AOB file that 
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is currently indicated for playback, out of the plurality 
of TKI included in the TrackManager . For this reason, the 
capacity of the TKI storing area 13 is equal to the data 
size of one TKI. 

5 

{52-4} FileKey Storing Area 14 

The FileKey storing area 14 is an area that is reserved 
for storing only the FileKey corresponding to the AOB file 
that is currently indicated for playback, out of the 
10 plurality of FileKeys included in "AOBSAl.KEY" in the 
authentication region. 

{52-5} Double Buffer 15 

The double buffer 15 is an input/output buffer that 
15 is used when an input process, which successively inputs 
cluster data (data that is stored in one cluster) read from 
the flash memory card 31, and an output process, which reads 
AOB_FRAMEs from cluster data and successively outputs the 
AOB_FRAMEs to the descrambler 7, are performed in parallel . 
20 The double buffer 15 successively frees the regions 

that were occupied by cluster data that has been outputted 
as AOB_FRAMEs and so secures regions for storing the next 
clusters to be read. This is to say, regions in the double 
buffer 15 are cyclically secured for storing cluster data 
25 using ring pointers. 
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{52-5_53_54A,B} Input and Output by the Double Buffer 15 
FIG. 53 shows how input and output are performed for 

the double buffer 15. FIGS. 54A and 54B show how regions 
5 in the double buffer 15 are cyclically secured for storing 

cluster data using a ring pointers. 

The arrows pointing downward and to the left are 

pointers to write addresses for cluster data^ which is to 

say, the write pointer. The arrows pointing upward and to 
10 the left are pointers to read addresses for cluster data, 

which is to say, the read pointer. These pointers are used 

as the ring pointer. 

{54-6_53) 

15 When a flash memory card 31 is connected to the card 

connector 1, cluster data in the user region of the flash 
memory card 31 is read out and stored in the double buffer 
15 as shown by the arrows wl and w2. 

The read cluster data is successively stored into the 

20 positions in the double buffer 15 shown by the write pointers 
wpl and wp2 . 

{52-7_54A) 

Of the AOB_Frames included in the cluster data stored 
25 in this way, the AOB_Frames present at the positions (1) 
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®(3aS)®®(x)®(3) that are successively indicated by the read 
pointer are outputted one at a time to the descrambler 7 
as shown by the arrows rl, t2, r3, r4, r5 .... 

In the present case, the cluster data 002 and 003 is 
5 stored in the double buffer 15 and the read positions 0 
(D(D® are successively indicated by the read pointer, as 
shown in FIG. 53. When the read pointer reaches the read 
position (D, all of the AOB_FRAMEs included in cluster 002 
will have been read, so that cluster 004 is read and, as 
10 shown by the arrow w6 in FIG. 54A, is overwritten into the 
region that was previously occupied by cluster 002. 
{52-8_54B> 

The read pointer then advances to the read positions 
(D and (2), and eventually reaches the read position (D, at 

15 which point all of the AOB_FRAMEs included in cluster 003 
will have been read, so that cluster 005 is read and, as 
shown by the arrow w7 in FIG. 54B, is overwritten into the 
region that was previously occupied by cluster 003. 

The output of an AOB_FRAME and the overwriting of cluster 

20 data are repeatedly performed as described above, so that 
the AOB_FRAMEs included in an AOB file are all successively 
outputted to the descrambler 7 and AAC decoder 8. 
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{52-9_55*58} Playback Control Program Stored in the ROM 
4 

The following describes the playback control program 
stored in the ROM 4. 
5 FIG. 55 is a flowchart showing the processing in the 

AOB file reading procedure, FIGS. 56, 57, and 58 are 
flowcharts showing the processing in the AOB_FRAME output 
procedure. 

10 {52-9_55-l} 

These flowcharts use the variables w, z, y, and x. 
The variable w indicates one of the plurality of DPL_TL_SRPs . 
The variable z indicates an AOB file recorded in the user 
region, the TKI corresponding to this AOB file, and the 

15 AOB included in this AOB file. The variable y indicates 
an AOB^ELEMENT included in the AOB#z indicated by the 
variable z . The variable x indicates an AOB_FRAME included 
in the AOB_ELEMENT#y indicated by the variable y. The 
following first explains the processing in the AOB file 

20 read procedure, with reference to FIG. 55. 

{52-9_55-2) 

In step SI, the CPU 10 reads the PlaylistManager and 
displays a list including the Def ault_Playlist_Inf ormation 
25 and the PLIs. 
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In step S2, the CPU 10 waits for an indication to play 
back AOBs in accordance with either the 
Default_Playlist_Infonnation or one of the PLIs. 

When the Default_Playlist_Information is indicated, 
5 the processingmoves from step S2 to step S3 where the variable 
w is initialized (#w^l) and then to step S4 where the TKI#z 
indicated by the DPL_TKIN corresponding to DPL_TK_SRP#w 
in the Default_Playlist_Infontiation is specified and only 
this TKI#z is read from the flash memory card 31 and stored 
10 into the TKI storing area 13. 

In step S5, an AOB f ile#z with the same number as TKI#z 
is specified. In this way, the AOB file that is to be played 
back is finally specified. 

The specified AOB file is in an encrypted state and 
15 needs to be decrypted, so that steps S6 and S7 are performed. 
In step S6, the playback apparatus accesses the 
authentication region and reads the FileKey#z that is stored 
in a FileKey_Entry#z in the encryption key storing file, 
the FileKey_Entry#z having the same number as the specified 
20 AOB file. In step S7, the CPU 10 sets the FileKey#z in the 
descrambler 7 . This operation results in the FileKey being 
set in the descrambler 7, so that by successively inputting 
AOB_FRAMEs included in the AOB file into the descrambler 
7, the AOB_FRAMEs can be successively played back. 

25 
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{52-9_55-3) 

After this, the playback apparatus successively reads 
the clusters that store the AOB file . In step S8 , the "first 
cluster number in the file" is specified for the A0B_file#2 

5 in the directory entry. In step S9, the CPU 10 reads the 
data stored in this cluster from the flash memory card 31. 
In step SIO, the CPU 10 judges whether the cluster number 
in the FAT value is "FFF". If not, in step Sll the CPU reads 
the data stored in the cluster indicated by the FAT value, 

10 before returning to step SIO. 

When the playback apparatus reads the data stored in 
any of the clusters and refers to the FAT value corresponding 
to this cluster, the processing in steps SIO and Sll will 
be repeated so long as the FAT value is not set at "FFF". 

15 This results in the playback apparatus successively reading 
clusters indicated by the FAT values . When the cluster 
number given by a FAT value is "FFF", this means that all 
of the clusters composing the AOB file#z have been read, 
so that the processing advances from step SIO to step S12. 

20 {52-9_55-4) 

In step S12, the CPU 10 judges whether the variable#w 
matches the total number of DPL_TK_SRPs. If not, the 
processing advances to step S13, where the variable#w is 
incremented (#w^#w+l) before the processing returns to step 

25 S4 . In step S4 , the playback apparatus specifies TKI#2 which 
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is indicated by the DPL_TKIN#w of DPL_TK_SRP#w in the 
Default_Playlist_Infonnation, and writes only TKI#2 into 
the TKI storing area 13. The TKI that was used up to this 
point will be still stored in the TKI storing area 13, though 

5 this current TKI will be overwritten by TKI#z that is newly 
read by the CPU 10. 

This overwriting results in only the latest TKI being 
stored in the TKI storing area 13. Once the TKI has been 
overwritten, the processing in steps S5 to S12 is repeated 

10 for the AOB file#z. Once this processing has read all of 
the TKI and AOB files corresponding to all of the DPL_TK_SRPs 
included in the Def ault_Playlist_Inf ormation, the variable 
#z will match the total number of DPL_TK_SRP so that the 
judgement "Yes" is given in step S12 and the processing 

15 in this flowchart ends. 



{52-9_56_57_58} Output Processing for an AOB^FRAME 

In parallel with the AOB file reading procedure, the 
CPU 10 performs the AOB_FRAME output procedure in accordance 

20 with the flowcharts shown in FIGS. 56, 57, and 58. In these 
flowcharts , the variable "play_time " shows how long playback 
has been performed for a current track, which is to say, 
the playback time code. The time displayed in the playback 
time code frame on the LCD panel 5 is updated in accordance 

25 with changes to this playback time code. Meanwhile, the 
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variable "play_data" represents the length of the data has 
been played back for the current track. 

{52-9_56-l) 

5 In step S21, the CPU 10 monitors whether cluster data 

for the AOB file#z has accumulated in the double buffer 
15 . This step S2 1 will be repeatedly performed until cluster 
data has accumulated, at which point the processing advances 
to step S22 where the variables x and y are initialized 

10 (#x-l, #y^l) . After this, in step S23 the CPU 10 searches 
the clusters for AOB file #z and detects the AOB_FRAME#x 
in the AOB_ELEMENT#y that is positioned no earlier than 
the Data_Offset given in the BIT#z included in TKI#z. In 
this example, it is assumed that the seven bytes starting 

15 from the SZ_DATA are occupied by the ADTS header. By 
referring to the ADTS header, the data length indicated 
by the ADTS header can be recognized as audio data. The 
audio data and ADTS header are read together and are outputted 
to the descrambler 7. The descrambler 7 decrypts the 

20 AOB_FRAMEs, which are then decoded by the AAC decoder 8 
and reproduced as audio. 

{52-9_56-2) 

After this detection, in step S24 the AOB_FRAME#x is 
25 outputted to the descrambler 7, and in step S25 the variable 
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play_time is incremented by the playback period of the 
AOB_FRAME#x and the variable play_data is incremented the 
amount of data corresponding the AOB__FRAME#x . Since the 
playback time of AOB_FRAME is 20msec in the present case, 
5 20msec is added to the variable "play_time". 

Once the first AOB_FRAME has been outputted to the 
descrambler 1 , in step S26 the playback apparatus refers 
to the ADTS header of AOB_FRAME#x and specifies where the 
next AOB_FRAME is. In step S27, the playback apparatus 

10 increments the variabletx (#x^#x+l) and sets AOB_FRAME#x 
as the next AOB_FRAME . In step S28 , AOB_FRAME#x is inputted 
into the descrambler 7. After this, in step S29, the 
variable play_time is incremented by the playback period 
of the AOB_FRAME#x and the variable play_data is incremented 

15 the amount of data corresponding the AOB_FRAME#x. After 
incrementing A0B_FR7\ME#x, in step S30 the CPU 10 judges 
whether the variable #x has reached the value given in 
FNs_lst_TMSRTE. 

If the variable #x has not reached the value in 

20 FNs_lst_TMSRTE, in step S31 the playback apparatus checks 
whether the user has pressed any key aside from the "Play" 
key, and then returns to step S26. The playback apparatus 
hereafter repeats the processing in steps S26 to S31 until 
the variable #x reaches the value in FNs_lst_TMSRTE or until 

25 the user presses any key aside from the "Play" key. 
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When the user presses a key aside from the "Play" key, 
the processing in this flowchart ends and suitable 
processing for the pressed key is performed. When the 
pressed key is the "Stop" key, the playback procedure stops, 
5 while when the pressed key is the "Pause" key, the playback 
is paused. 

{52-9_57-l) 

On the other hand, when the variable #x reaches the 

10 value in FNs_lst_TMSRTE, the judgement "Yes" is made in 
step S30, and the processing proceeds to step S32 in FIG. 
57. Since all of the AOB_FRAMEs included in the present 
AOB_ELEMENT will have been inputted into the descrambler 
7 in the processing between step S26 to S30, in step S32 

15 the variable #y is incremented to set the next AOB_ELEMENT 
as the data to be processed and the variable #x is initialized 
(#y^#y+l,#x^l) . 

After this, in step S33 the playback apparatus refers 
to the TKTMSRT and calculates the first address of the 

20 AOB_ELEMENT#y. 

The playback apparatus then performs the procedure 
made up of steps S34 to S42. This procedure reads the 
AOB_FRAMEs included in an AOB_ELEMENT one after another, 
and so can be said to resemble the procedure made up of 

25 steps S24 to S31. The difference with the procedure made 
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Up of steps S24 to S31 is the condition by which the procedure 
made up of steps S24 to S31 ends is whether the variable 
#x has reached the value shown by "FNs_lst_TMSRTE"^ while 
the condition by which procedure made up of steps S34 to 

5 S42 ends is whether the variable #x has reached the value 
shown by "FNs_Middle_TMSRTE" . 

When the variable #x reaches the value shown by 
"FNs_Middle_TMSRTE", the loop procedure made up of steps 
S34 to S42 ends, the judgement "Yes" is given in step S41 

10 and the processing advances to step S43, In step S43, the 
CPU 10 increments the variable #y and initializes the 
variable #x (#y^#y+l, #x^l) . After this, in step S44 the 
variable y judges whether the variable #y has reached a 
value that is equal to one less than the 

15 TotalTMSRT_entry_Number in the TMSRT_Header in the TKI#z. 
When the variable #y is lower than 
{TotalTMSRT_entry_Number-l) , the AOB_ELEMENT#y is not the 
final AOB_ELEMENT, so that the processing returns from step 
S44 to step S32 and the loop procedure of step S32 to step 

20 S42 is performed. When the variable #y reaches 

(TotalTMSRT_entry_Number-l) the read procedure can be 
assumed to have proceeded as far as the penultimate 
AOB_ELEMENT, SO that the judgement "Yes" is given in step 
S44 and the processing advances to step S45 in FIG, 58. 

25 
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{52-9_57-2) 

The procedure composed of steps S45 to S54 resembles 
the procedure composed of steps S33 to S42 in that each 
of the AOB_FRAMEs in the final AOB_ELEMENT are read. 

5 The difference with the procedure composed of steps 

S33 to S42 is that while the loop procedure composed of 
steps S33 to S42 ends when it is judged in step S41 that 
the variable #x has reached the value in "FNs_Middle_TMSRTE", 
the loop procedure composed of steps S45 to S54 ends when 

10 it is judged in step S53 that the variable #x has reached 
the value in "FNs_Last_TMSRTE" and the variable play_data 
showing the size of the data that has hitherto been read 
has reached the value given as "SZ_DATA". 

The procedure composed of steps S49 to S54 is repeated 

15 until the conditions in step S53 are satisfied, at which 
point the judgement "Yes" is given in step S53 and the 
processing advances to step S55. In step S55, the CPU 10 
increments the variable #z (#2*-#z+l) before the processing 
returns to step S21 where the CPU 10 waits for the next 

20 AOB file to accumulate in the double buffer 15. Once this 
happens, the processing advances to step S22 and the 
procedure composed of steps S22 to step S54 is repeated. 
This means that the TKI indicated by the DPL TKIN of the 
next DPL_TK_SRP is specified and the AOB file corresponding 

25 to this TKI, which is to say, the AOB file with the same 
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number as the TKI, is specified. 

After this, the playback apparatus accesses the 
authentication region and specifies the FileKey, out of 
the FileKeys in the encryption key storing file, that has 
5 the same number as the TKI, before reading this FileKey 
and setting it in the descrambler 7. As a result, the 
AOB_FRAMEs included in the AOB file having the same number 
as the TKI are successively read and played back. 

10 {52-9_57-3_59) XT^xiating of the Playback Time Code 

FIGS. 59A to 59D show how the playback time code 
displayed in the playback time code display frame of the 
LCD panel 5 is increased in accordance with the updating 
of the variable play_time. In FIG. 59A, the playback time 

15 code is "00:00:00.000", though when the playback of 

A0B_FRAME#1 ends, the playback period 20msec of A0B_FRAME#1 
is added to the playback time code to update it to 
"00:00:00.020", as shown in FIG. 59B. When the playback 
of A0B_FRAME#2 ends, the playback period 20msec of 

20 A0B_FRAME#2 is added to the playback time code to update 
it to "00:00:00.040", as shown in FIG. 59C. In the same 
way, when the playback of A0B_FRAME#6 ends, the playback 
period 20msec of A0B_FRAME#6 is added to the playback time 
code to update it to "00:00:00.120", as shown in FIG. 59D. 

25 This completes the description of the AOB_FRAME output 
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procedure . 

In step S31 of the flowchart in FIG. 56^ if the user 
presses a key aside from the "Play" key, the processing 
in this flowchart is terminated. The processing that 

5 accompanies a pressing of "Stop" or "Pause" key has already 
been described, though when the user presses one of the 
keys provided to have the playback apparatus perform special 
playback, the processing in this flowchart, or in the 
flowcharts shown in FIGS. 56, 57, or 58 is terminated and 

10 suitable processing for the pressed key is performed. 

The following describes the procedure executed by the 
CPU 10 (1) when performing the forward search function in 
response to the user pressing the "»" key and (2) when 
performing the time search function in response to the user 

15 operating the jog dial after pressing the "Pause" or "Stop" 
key. 

{52- 10^60} Forward Search Function 

FIG. 60 is a flowchart showing the procedure executed 
20 by the CPU 10 when performing the forward search function. 
When the user presses the "»" key, the judgement "Yes" 
is given in step S31, step S42 or step S54 in the flowcharts 
in FIGS. 56, 57 and 58 and the CPU 10 performs the processing 
in the flowchart of FIG. 60. 
25 In step S61, the AOB_FRAMEs #x to #(x+f(t)-l) are 
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inputted into the descrambler 7. Here "t" represents the 
intermittent playback period, f (t) represents the number 
of frames corresponding to the intermittent playback period, 
and d(t) represents the amount of data corresponding to 

5 the intermittent playback period. InstepS62, the variable 
play_time showing the playback elapsed time, and the 
variable play_data showing the playback data amount are 
respectively updated using intermittent playback period 
"t", the number of frames f (t) corresponding to intermittent 

10 playback period, and the amount of data d(t) corresponding 
to the intermittent playback period (x^x+f(t), 
play_time-play_time+t, play_data-play_data+d (t) ) . Note 
that the intermittent playback period will generally be 
240 msec (equivalent to the playback period of twelve 

15 AOB_FRAMEs) . 

{52-10_60-l_6lA,B) 

FIGS . 61A and 61B show the incrementing of the playback 
time code during a forward search operation . FIG . 61A shows 
20 the initial value of the playback time code, with the playback 
point being the A0B_FRAME#1 in A0B_ELEMENT#51 • 

The playback time code in this case is "00:00:01.000". 
When the first to twelve AOB_FRAMEs have been inputted into 
the descrambler 7 as the intermittent playback period, the 
25 playback period of twelve AOB_FRAMEs (i.e., 240msec) is 
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added to the playback time code so that the playback time 
code becomes "00:00:01.240", as shown in FIG. 61B. 

{52-10_60-2) 

5 After this updating, in step S63 the CPU 10 compares 

the incremented variable #x with the total number of frames 
in AOB_ELEMENT#y and j udges whether the incremented variable 
#x is within the total number of frames in AOB_ELEMENT#y. 
As mentioned earlier, the number of frames in an 

10 AOB_ELEMENT positioned at the start of an AOB is 

"FNs_lst_TMSRTE", the number of frames in an AOB_ELEMENT 
positioned in a central part of an AOB is "FNs_Middle_TMSRTE" , 
and the number of frames in an AOB_ELEMENT positioned at 
the end of an AOB is "FNs_Last_TMSRTE" . 

15 The CPU 10 performs the above judgement by comparing 

an appropriate one of these values with the variable #x. 
When the variable x is not within the present AOB_ELEMENT#y, 
the CPU 10 then judges in step S64 whether there is an 
. AOB_ELEMENT that follows the AOB_ELEMENT#y . 

20 When the AOB_ELEMENT#y is the final AOB_ELEMENT in an 

AOB_BLOCK, there will be no AOB_ELEMENT that follows the 
AOB_ELEMENT#y, so that the judgement "No" is given in step 
S64 and the processing in the present flowchart ends. 
Conversely, when an AOB_ELEMENT that follows the 

25 AOB_ELEMENT#y exists, in step S65 the variable #x is reduced 
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by the number of A0B_FR7\MEs in the AOB_ELEMENT#y and in 
step S66 the variable#y is updated (#y^#y+l) . As a result, 
the variable#x will now indicate the frame position of a 
frame in the next AOB_ELEMENT#y indicated by the updated 
5 variable #y. Conversely, when the variable #x indicates 
an AOB_FRAME that is present in the current AOB__ELEMENT 
(S63:Yes) , the processing in steps S64-S66 is skipped and 
the processing advances to step S67. 

10 {52-10_60-3) 

After this, the variables #x, play_time, and play_data 
are updated in accordance with the intermittent skip period. 
The period "skip_time" that is equivalent to the 
intermittent skip period is two seconds , the number of frames 

15 that are equivalent to this skip_time is given as 

f (skip_time) and the amount of data that is equivalent to 
this skip_time is given as d (skip__time) . In step S67, these 
values are used to update the variables #x, play_time, and 
play_data (#x^#x+f (skip_time) , play_time^ 

20 play_time+skip_time, and play_data*- 
play_data+d(skip_time) ) . 

{52-10_60-4_61C) 

As shown in FIG. 61C, the intermittent skip period is 
25 added to the variable#x showing a frame position within 
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the A0B_ELEMENT#51. When the updated variable #x exceeds 
the number of frames in A0B__ELEMENT#51, the variable #y 
is updated to indicate the next AOB_ELEMENT and the number 
of frames in the A0B_ELEMENT#51 is subtracted from the 

5 variable #x. As a result, the variable#x will now indicate 
a frame position within the AOB_ELEMENT#52 indicated by 
the updated variable #y. The value 2.000 (=2sec) is then 
added to the present value "00:00:01.240" of the playback 
time code so that it becomes "00:00:03.240". The variable 

10 #x is updated by calculating (3240msec-2000msec) /20msec) 
to give the value "62", and so indicates the AOB_FRAME#62 
in the AOB_ELEMENT#52 . 

{52-10_60-5_61 (d) ) 

15 Once the AOB_FRAME#62 in the AOB_ELEMENT#52 has been 

inputted into the descrambler 1 , the playback time code 
is updated as shown in FIG. 61D by adding "0.240" to the 
present value of "00:00:03.240" to give "00:00:03.480". 
In step S67, the variables are updated in accordance 

20 with the intermittent skip time and then the processing 
in steps S68 to S71 are performed. This processing in steps 
S68 to S71 is the same as the processing in steps S63 to 
S66 and so updates the variable#x by a number of frames 
that is equivalent to the intermittent skip time "skip_time" , 

25 before checking whether the variabletx still indicates an 
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AOB_FRAME within the present AOB_ELEMENT#y . If not, the 
variable #y is updated so that the next AOB_ELEMENT is set 
as the AOB_ELEMENT#y and the variable#x is converted so 
as to indicate a frame position in this next AOB_ELEMENT. 

5 Once the variables #x and #y have been in accordance 

with the intermittent playback time and intermittent skip 
time, in step S72 the CPU 10 refers to the TKTMSRT and 
calculates the start address for the AOB_ELEMENT#y . Then, 
in step S73, the CPU 10 starts to search for an ADTS header 

10 starting from the start address of the AOB_ELEMENT#y to 
detect the AOB_FRAME#x. In step S74, the CPU 10 judges 
whether the user has pressed any key aside from the forward 
search key. If not, the AOB_FRAMEs from the AOB__FRAME#x 
to the AOB_FRAME#x+f (t) -1 are inputted into the descrambler 

15 7, and the processing in steps S62 to S73 is repeated. 

The above procedure increments the variables #x and 
#y that indicate the AOB_FRAME#x and AOB_ELEMENT#y, and 
so advances the playback position. After this, if the user 
presses the "Play" key, the judgement "No" is given in FIG. 

20 74 and the processing in the present flowchart ends. 

{52-11} Execution of the Time Search Function 

The following describes the processing performed when 
the time search function is used. First, the tracks in the 
25 Default_Playlist_Information are displayed and the user 
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indicates a desired track. When this track has been 
indicated and the user has operated the j og dial , the playback 
time code is updated. If the user then presses the "Play" 
key, the playback time code at that point is used to set 

5 a value in the variable "Jmp_Entry" in seconds. 

A judgement is then made as to whether the indicated 
track is composed of a plurality of AOBs or a single AOB. 
When the track is composed of a single AOB, the variables 
#y and #x are calculated so as to satisfy Equation 2 . After 

10 this , a search for the AOB_FRAME#x is started from the address 
in the (y+2)*'' position in the TKTMSRT corresponding to this 
AOB. Once this AOB_FRAME#x has been found, playback starts 
from AOB_FRAME#x. 

15 {52-12} 

When the track is composed of a plurality of AOBs, the 
variables #n (indicating an AOB) , #y and #x are calculated 
so as to satisfy Equation 3. After this, a search for the 
A0B_FR7\ME#x is started from the address in the (y+2)*'' 
20 position in the TKTMSRT corresponding to AOB#n. Once this 
AOB_FRAME#x has been found, playback starts from 
AOB_FRAME#x. 

The following describes the case when playback is 
commenced from an arbitrary position with an AOB where the 
25 "FNs_lst_TMSRTE" in the BIT is "80 frames", 
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"FNs_Middle_TMSRTE" in the BIT is "94 frames", and the 
"FNs_Last_TMSRTE" in the BIT is "50 frames". 

{52-13_62A,B) 

5 As one specific example of when the time search function 

is used, the following describes how the AOB_ELEMENT and 
frame position from which playback should start are 
specified when a playback time code is indicated using the 
jog dial. 

10 As shown in FIG. 62A, the user holds the playback 

apparatus in his/her hand and rotates the jog dial with 
his/her right thumb to indicate the playback time code 
"00 : 04 : 40 . 000 (=280sec) " . When the BIT in the TKI for this 
AOB is as shown in FIG. 62B, Equation 2 is used as follows 

15 

280sec= (FNs_lst_TMSRTE+ (FNs_Middle_TMSRTE*y) +x) *20msec 
=(80+{94*148)+8)*20msec 

so that the Equation 2 is satisfied for the values y==148 
20 and x=8. 

Since y=148, the entry address of the AOB_ELEMENT#150 
(=148+2) is obtained from the TKTMSRT. Playback from the 
indicated playback time code 00:04 : 40. 000 (=280. OOsec) can 
then be performed by starting the playback at the eighth 
25 AOB_FRAME from this entry address. 
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{52-14_63_64_65} 

This completes the explanation of the processing of 
the CPU 10 in response to the user pressing the "Play" key. 

5 The following describes the editing control program stored 
in the ROM 4 . This editing control program is executed when 
the user presses the "Edit" key, and contains the procedures 
shown in FIGS- 63, 64, and 65. The following describes the 
processing in this program with the flowcharts shown in 

10 these drawings. 

{52-14_63--l) Editing Control Program 

When the user presses the "Edit" key, an interactive 
screen is displayed in step SlOl in FIG. 63 to ask the user 

15 which of the three fundamental editing operations "deletion" , 
"division" and "combining" is to be performed. In step S102, 
the CPU 10 judges what operation has been made by the user 
in response to the interactive screen. In the present 
example, it is assumed that the "|«" and "»|" keys on the 

20 key panel are also used as indicating "Up" and "Down" cursor 
operations, (i.e., these keys are used as "Up" and "Down" 
cursor keys) . When the user indicates a "deletion" 
operation, the processing proceeds to the loop procedure 
composed of steps S103 and S104. 

25 In step S103, the CPU 10 judges whether the user has 
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pressed the "|«" or "»|" key. In step S104, the CPU 10 
judges whether the user has pressed the "Edit" key. When 
the user has pressed the "|«" or "»!" key, the processing 
advances from step S103 to S105, where the indicated track 
5 is set as the track to be edited. On the other hand, when 
the user has pressed the "Edit" key, the indicated track 
is set as a track to be deleted. The processing shown in 
FIG. 44 is executed, so that the TKI_BLK_ATR of each TKI 
for the indicated track is set at "Unused" to delete the 
10 indicated track. 

{52-14_63-2} Combining Process 

When the user selects the combining process, the 
processing proceeds from step S102 to the loop procedure 

15 composed of steps S107 to S109. In the loop procedure 
composed of steps S107 to S109, the playback apparatus 
receives user inputs via the "l«", "»l", and "Edit" keys. 
When the user presses the "|«" or "»|" key, the processing 
advances from step S107 to step SllO where the indicated 

20 track is highlighted on the display. When the user presses 
the "Edit" key, the judgement "Yes" is given in step S108 
and the processing advances to step Sill. In step Sill, 
the currently indicated track is set as the first track 
to be used in this editing process and the processing returns 

25 to the loop procedure composed of steps S107 to S109. 
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When a second track has been selected for editing, 
the judgement "Yes" is given in step S109, and the processing 
advances to step S112. In step S112, the CPU 110 refers 
to the BITS in the TKIs of the former and the latter tracks 

5 and judges what kind of AOBs (Typel or Type2) are present 
at the respective start and end of each of these tracks 
and tracks on either side of these tracks, if present. 

After identifying the type of each relevant AGE, in 
step S113 the CPU 10 judges whether the arrangement of AOBs 

10 matches a certain pattern. When the arrangement of AOBs 
matches one of the four patterns shown in FIG. 32A to 32D 
where it is clear that three Type2 AOBs will not be present 
consecutively after the combining, the former and latter 
tracks are combined into a single track in step S115. 

15 In the other words, the operation shown in FIG. 4 6 is 

performed for the TKI and DPL_TK_SRP corresponding to these 
AOBs. By rewriting the TKI_BLK_ATRs in the TKIs, the 
plurality of tracks selected for editing are combined into 
a single track. When the arrangement of AOBs does not match 

20 any of the patterns in FIGS. 32A to 32D, meansing that there 
will be three or more Type2 AOBs after the combining, the 
CPU 10 judges that the combined track may cause a buffer 
underflow and so terminates the combining process. 

25 
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{52-14^64-1} Track Division Process 

When the user indicates that a track is to be divided, 
the processing advances from step S102 to the loop procedure 
composed of steps S116 to S117. In the loop procedure 
5 composed of steps S116 to S117, the playback apparatus 
receives user inputs via the "»!", and "Edit" keys. 

When the user presses the "|«" or "»|" key, the 
processing advances from step S116 to step S118 where the 
indicated track is set as the track to be edited. When the 
10 user presses the "Edit" key, the judgement "Yes" is given 
in step S117 and the processing advances to step S119. 

In step S119, the indicated track is determined as the 
track to be edited and the processing advances to step S120 
where the playback of this track is commenced. In step S121, 
15 the playback apparatus receives a user input via the "Mark" 
key. 

When the user presses the "Mark" key, the playback of 
the track is paused and the processing advances to the loop 
procedure composed of steps S122 and S123. In step S122, 
20 the playback apparatus receives user operations made via 
the jog dial. When the user rotates the jog dial, the 
playback time code is updated in step S124 in accordance 
with the rotation of the jog dial. 

After this, the loop procedure composed of steps S122 
25 and S123 is repeated. If the user presses the "Edit" key, 
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the processing proceeds from step S123 to step S125, where 
the playback time code displayed when the user pressed the 
"Edit" key is set as the division boundary. Note that an 
"Undo" function may be provided for this setting of the 
5 division boundary to allow the user to invalidate the 
selected division boundary. 

After this, the processing explained with reference 
to FIG. 47 is executed in step S126 to update the DPLI and 
TKI so as to divide the selected track. 

10 

{52-14_65-l) Process Setting a Playlist 

When the user chooses to set a Playlist, the processing 
switches to the procedure shown by the flowchart in FIG. 
65. In this flowchart, the variable k given in this 

15 flowchart is used to indicate the position of a track in 
the playback order given by the Playlist that is being edited . 
The flowchart in FIG. 65 starts with this variable k being 
initialized to "1" in step S131, before the processing 
advances to the loop procedure composed of steps S132 to 

20 S134. 

In the loop procedure composed of steps S132 to S134, 
the playback apparatus receives user operations made via 
the "|«", "»l", "Edit", and "Stop" keys. When the user 
presses the "|«" or "»|" key, the processing advances from 
25 step S132 to step S135 where a new track is indicated in 
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accordance with the pressing of the "|«" or ">>!" key. If 
the user presses the "Edit" key, the judgement "Yes" is 
given in step S133 and the processing advances to step S136. 
In step S136, the track indicated when the user presses 
5 the "Edit" key is selected as the kth track in the playback 
order. After this, in step S137 the variable k is 
incremented and the processing returns to the loop procedure 
composed of steps S132 to S134. This procedure is repeated 
so that the second, third and fourth tracks are successively 
10 selected. If the user presses the "Stop" key have specified 
several tracks that are to be played back in the specified 
order as a new Playlist, the processing advances from step 
S134 to step S138 where a PLI composed of PL_TK_SRPs that 
specify the TKIs corresponding to these tracks is generated. 

15 

{66-1} Recording i^paratus 

The following describes one example of a recording 
apparatus for the flash memory card 31. FIG. 66 shows one 
example of a recording apparatus . This recording apparatus 

20 can be connected to the Internet, and is a standard personal 
computer that can perform reception when an encrypted 
SD-Audio directory is sent via communication lines to the 
recording apparatus by an electronic music distribution 
service, or when an audio data transport stream is sent 

25 via communication lines to the recording apparatus by an 
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electronic music distribution service, 

{67-1} Hardware Composition of the Recording i^pparatus 

FIG. 67 shows the hardware composition of the present 

5 recording apparatus. 

As shown in FIG, 67, the recording apparatus includes 
a card connector 21 for connecting the recording apparatus 
to the flash memory card 31, a RAM 22, a non-removable disk 
apparatus 23 for storing a recording control program 

10 that performs overall control over the recording apparatus, 
an A/D converter 24 that A/D converts audio inputted via 
a microphone to produce PCM data, an ACC encoder 25 for 
encoding the PCM data in units of a fixed time and assigning 
ADTS headers to produce AOB_FRAMEs, a scrambling unit 26 

15 for encrypting the AOB_FRAMEs using a different FileKey 
for each AOB_BLOCK, a modem apparatus 27 for receiving an 
audio data transport stream when an encrypted SD-Audio 
directory is sent via communication lines to the recording 
apparatus by an electronic music distribution service, or 

20 when an audio data transport stream is sent via communication 
lines to the recording apparatus by an electronic music 
distribution service, a CPU 28 for performing overall 
control over the recording apparatus, a keyboard 29 for 
receiving inputs made by the user, and a display 30. 

25 

140 



wo 00/74061 



PCT/JPOO/03300 



{67-2} Input Circuits RTl to RT4 

When an encrypted SD-Audio directory, which is to be 
written in the data region and the authentication region, 
is sent via communication lines to the recording apparatus 
5 by an electronic music distribution service, the recording 
apparatus can write the encrypted SD-Audio directory into 
the data region and authentication region of the flash memory 
card 31 as soon as the encrypted SD-Audio directory has 
been properly received. 

10 However, (1) when an audio data transport stream that 

is not in the form of SD-Audio directory is sent to the 
recording apparatus by an electronic music distribution 
service, (2) when data is inputted into the recording 
apparatus in PCM format, or (3) when analog audio is recorded 

15 by the recording apparatus, the recording apparatus uses 
the following four input routes to write an audio data 
transport stream onto the flash memory card 31. 

As shown in FIG. 67, the four input routes RTl, RT2, 
RT3, and RT4 are used to input an audio data transport stream 

20 when an audio data transport stream is stored in the flash 
memory card 31. 

(67-3) Input Route RTl 

The input route RTl is used when an encrypted SD-Audio 
25 directory is sent via communication lines to the recording 
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apparatus by an electronic music distribution service, or 
when an audio data transport stream is sent via communication 
lines to the recording apparatus by an electronic music 
distribution service • In this case, the AOB_FRAMEs 

5 included in the transport stream are encrypted so that a 
different FileKey is used for the AOB_FRAMEs in different 
AOBs. Since there is no need to encrypt or encode an 
encrypted transport stream, the SD-Audio directory or audio 
data transport stream can be stored directly into the RAM 

10 22 in its encrypted state. 

{67-4} Input Route RT2 

Input route RT2 is used when audio is inputted via a 
microphone. In this case, the audio inputted via the 

15 microphone is subjected to A/D conversion by the A/D 
converter 24 to produce PCM Data . The PCM data is then encoded 
by the AAC encoder 25 and assigned ADTS headers to produce 
AOB_FRAMEs. After this, the scrambling unit 26 encrypts 
the AOB_FRAMEs using a different FileKey for each AOB_FRAMEs 

20 in different AOB_FILEs to produce encrypted audio data. 
After this, the encrypted audio data is stored in the RAM 
22. 

{67-5) Input Route RT3 

25 Input route RT3 is used when PCM data read from a CD 
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is inputted into the recording apparatus- Since data is 
inputted in PCM format, the data can be inputted as it is 
into the AAC encoder 25. This PCM data is encoded by the 
ACC encoder 25 and assigned ADTS headers to produce 
5 AOB_FRAMEs . 

After this, the scrambling unit 26 encrypts the 
AOB_FRAMEs using a different FileKey for the AOB_FRAMEs 
in different AOBs to produce encrypted audio data. After 
this, the encrypted audio data is stored in the RAM 22. 

10 

{67-6) Input Route RT4 

The input route RT4 is used when a transport stream 
inputted via one of the three input routes RTl, RT2, and 
RT3 is written into the flash memory card 31. 

15 This storing of audio data is accompanied by the 

generation of TKIs and Default_Playlist_Information. In 
the same way as the playback apparatus, the main functioning 
of the recording apparatus is stored in the ROM. This is 
to say, a recording program that includes the characteristic 

20 processing of the recording apparatus, which is to say, 
the recording of AOBs, the TrackManager, and the 
PlaylistManager, is stored in the non-removable disk 
apparatus 23. 

25 
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{67-7_68} Processing of the Recording Apparatus 

The following describes the processing in the recording 
procedure that writes a transport stream in the flash memory 
card 31 via the input routes RTl, RT2, RT3 and RT4, with 
5 reference to the flowchart in FIG. 68 that shows this 
processing. 

The variables "Frame_N umber" and "Data_Size" used in 
this flowchart are as follows. The variable Frame Number 
is used to manage the total number of AOB_FRAMEs that have 

10 already been recorded in an AOB_FILE. The variable 

Data_Size is used to manage the data size of the AOB FRAMES 
that have already been recorded in the AOB_FILE. 

The processing in this flowchart starts in step S200 
with the CPU 28 generating the Def aultPlaylist and the 

15 TrackManager . In step S201, the CPU 28 initializes the 
variable #z (z^l) . In step S202, the CPU 28 generates the 
AOB_FILE#z and stores it in the data region of the flash 
memory card 31. At this point, the filename, filename 
extension, and first cluster number for the AOB_FILE#z will 

20 be set in a directory entry in the SD_Audio Directory in 
the data region. After this, in step S203, the CPU 28 
generates TKI#z and stores it in the TrackManager. In step 
S204, the CPU 28 generates the DPL_TK_SRP#w and stores it 
in the Def ault_Playlist_Information . After this, in step 

25 S205 the CPU 28 initializes the variable#y (#y^l) and in 
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Step S206, the CPU 28 initializes the Frame_Number and 
Data^Size (Frame_Number^O, Data_Size^O) . 

In step S207, the CPU 28 judges whether the input of 
the audio data transport stream that should be written in 

5 the AOB_FILE# has ended. When the input of an audio data 
transport stream that has been encoded by the AAC encoder 
25 and encrypted by the scrambling unit 2 6 into the RAM 
22 continues and it is necessary to continue the writing 
of cluster data^ the CPU 28 gives the judgement "No" in 

10 step S207 and the processing advances to step S209. 

In step S209, the CPU judges whether the amount of AAC 
audio data that has accumulated in the RAM 22 is at least 
equal to the cluster size. If so, the CPU 28 gives the 
judgement "Yes" and the processing advances to step S210 

15 where an amount of KkC audio data equal to the cluster size 
is written into the flash memory card 31. The processing 
then advances to step S211. 

When sufficient AAC audio data has not accumulated 
in the RAM 22, stepS210 is skipped and the processing advances 

20 to step S211. In step S211, the CPU increments the 

Frame_Number (Frame_Number^Frame_Number+l) and increases 
the value of the variable Data_Size by the data size of 
the AOB_FRAME. 

After this updating, in step S212 the CPU 28 judges 

25 whether the value of Frame_Number has reached the number 
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of frames that is set in "FNs_Midcile_TMSRTE", the value 
of "FNs_Middle_TMSRTE" is set in accordance with the 
sampling frequency used when encoding the audio data 
transport stream. When the value of Frame_Nuraber has 

5 reached the number of frames set in "FNs_Middle_TMSRTE", 
the CPU 28 gives the judgement "Yes" in step S212. If not, 
the CPU 28 gives the judgement "No" and the processing returns 
to step S207. The processing in steps S207 to S212 is 
therefore repeated until the judgement "Yes" is given in 

10 either step S207 or in step S212. 

When the variable Frame_Number reaches the value of 
"FNs_Middle_TMSRTE", the CPU 28 gives the judgement "Yes" 
in step S212 and the processing advances from step S212 
to step S213 where Data_Size is stored in the TKTMSRT of 

15 TKI#z as the TMSRT_entry#y for the AOB_ELEMENT#y. In step 
S214, the CPU 28 increments the variable#y (#y*-#y+l) before 
checking in step S215 whether the variable#y has reached 
"252". 

The value "252" is used since this is the maximum number 
20 of AOB_ELEMENTs that can be stored in a single AOB. If the 
variable #y is below 252, the processing advances to step 
S216, where the CPU 28 judges whether a silence of a 
predetermined length is present in the encoded audio, which 
is to say that the audio data has reached a gap present 
25 between tracks . When no such continuous silence is present, 
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the processing composed of steps S206 to S215 is repeated. 
When the variable#y has reached the value 252, or a silence 
of a predetermined length is present in the encoded audio, 
the judgement "Yes" is given in one of steps S215 and S216 

5 and the processing advances to step S217 where the variable#z 
is incremented (#z^#z+l) . 

After this, the processing in steps S202 to S216 is 
repeated for the incremented variable#z • By repeating this 
processing, the CPU 28 can have AOBs including a plurality 

10 of AOB_ELEMENTs recorded one after the other into the flash 
memory card 31. 

When the transfer of an audio data transport stream 
by the AAC encoder 25, the scrambling unit 2 6, and the modem 
apparatus 27 is complete, this means that the input of the 

15 audio data transport stream to be written into the AOB_FILE#z 
will also be complete, so that the judgement "Yes" is given 
in step S207 and the processing advances to step S208. In 
step S208, the CPU 28 stores the value of the variable 
Data_Size in the TKTMSRT of the TKI#z as the TMSRT_Entry#y 

20 for the AOB_ELEMENT#y . After storing the audio data 

accumulated in the RAM 22 in the AOB file corresponding 
to the AOB#z, the processing in this flowchart ends. 

The above processing results in an encrypted audio data 
transport stream being stored in the flash memory card 31. 

25 The following procedure is then used to store the FileKey 
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required for decrypting this encrypted audio data transport 
stream in the authentication region. 

When the audio data transport stream has been inputted 
via input route RTl, the AOB file(s) , the file storing the 

5 TKMG, the file storing the PLMG, and the encryption key 
storing file storing a different FileKey for each AOB are 
sent to the recording apparatus by a provider of the 
electronic music distribution service . The CPU 28 receives 
these files and writes the AOB file(s), the file storing 

10 the TKMG, and the file storing the PLMG into the user region 
of the flash memory card 31. On the other hand, the CPU 
28 writes only the encryption key storing file storing a 
different FileKey for each AOB into the authentication 
region. 

15 When the audio is inputted via the input route RT2 or 

RT3, the CPU 28 generates a different FileKey every time 
the encoding of a new AOB commences and sets the generated 
key in the scrambling unit 26. In addition to being used 
by the scrambling unit 26 to encrypt the present AOB, this 

20 FileKey is stored following the FileKey Entry in the 
encryption key storing file present in the authentication 
region. 

With the present embodiment describes above, the files 
storing AOBs are encrypted using different encryption keys, 
25 so that if the encryption key used to encrypt one file is 
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decoded and exposed, the exposed encryption key can only 
be used to decrypt a file storing one AOB, with such exposure 
having no effect on other AOBs that are stored in other 
files . This minimizes the damage caused when one encryption 

5 key is exposed. 

Note that while the above description focuses on an 
example system that is thought to be the most effective 
embodiment of the present invention, the invention is not 
limited to this system. Various modifications are possible 

10 within the scope of the invention, with examples of the 
such being given as (a) to (e) below. 

(a) The above embodiment describes a semiconductor 
memory (flash memory card) as the recording medium used, 
though the present invention can be applied to other media 

15 including optical discs, such as DVD-RAM, or a hard disk. 

(b) In the above embodiment, the audio data was 
described as being in AAC format, though the present 
invention can also be applied to audio data in another format 
suchasMP3 (MPEG 1 Audio Layer 3), Dolby-AC3, orDTS (Digital 

20 Theater System) . 

(c) While the file storing the TKMG and the file storing 
the PLMG were described as being received from the provider 
of the electronic music distribution service in a complete 
form, the main information used to create the TKMG and PLMG 

25 can be transmitted together with the encryption key storing 
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file that stores a different encryption key for each AOB, 
The recording apparatus may then process this information 
to obtain the TKMG and PLMG which it then records in the 
flash memory card. 
5 (d) For ease of explanation, the recording apparatus 

and playback apparatus were described as being separate 
devices, though a portable playback apparatus can be 
equipped with the functioning of the recording apparatus 
and a recording apparatus in the form of a personal computer 

10 can be equipped with the functions of the playback apparatus . 
Aside from the portable playback apparatus and personal 
computer recording apparatus, the functions of the playback 
apparatus and recording apparatus can also be provided to 
a communication device that is capable of downloading 

15 content from a network. 

As one example, a mobile telephone capable of Internet 
access may be provided with the functions of the playback 
apparatus and recording apparatus described in the above 
embodiment. This mobile telephone may store contents 

20 downloaded via a wireless network in the flash memory card 
31 in the same way as in the above embodiment. Also, while 
the recording apparatus described in the above embodiment 
is provided with the modem apparatus 27 for connecting to 
the Internet, any other device capable of connecting to 

25 the Internet, such as a terminal adapter for an ISDN line. 
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may be provided instead. 

(e) The procedures shown in the flowcharts shown in 
FIGS. 55 to 58, FIG. 60, FIG. 63 to FIG. 65, and FIG. 68 
can be achieved by executable programs that may be 
distributed and sold having been recorded on a recording 
medium. This recording medium may be an IC card, an optical 
disc, a floppy disk, or the like, with the programs recorded 
on the recording medium being used having first been 
installed into standard computer hardware. By performing 
processing in accordance with such installed programs, 
standard computer hardware can perform the same functioning 
as the playback apparatus and recording apparatus described 
in the above embodiment. 

(f ) While the above embodiment describes the case where 
a plurality of AOBs and a plurality of FileKeys are stored 
on the flash memory card 31, only one AOS and one FileKey 
need be stored. Also, it is not essential for the AOBs to 
be encrypted, so that AOBs may be stored on the flash memory 
card 31 in ACC format. 

SECOND EMBODIMENT 

The second embodiment of the present invention relates 
to an improvement in the storage of still images together 
with the AOB files described in the first embodiment . These 
still images are to be displayed when the AOB files are 
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played back. 

{69-1} Hierarchical Construction of the Flash Memory Card 
of the Second Embodiment 

5 FIG. 69 shows the hierarchical construction of the 

flash memory card 31 of this second embodiment. The 
hierarchical construction . for the flash memory card 31 
described in this embodiment differs from that of the first 
embodiment in that POBs (picture objects) have been added 

10 to the presentation data and a POBManagers has been added 
to the navigation data. POBs are pieces of still image data 
in JPEG (Joint Photographic Experts Group) format and are 
referred to by the PlaylistManager and the TrackManager . 
The POBManager is management information that describes 

15 how the POBs should be referred to by the PlaylistManager 
and the TrackManager. 

{69'-1^70A-l} Composition of the User Data Area in the File 
System Layer 

20 Since extra information is added to the presentation 

data and navigation data in this embodiment, the internal 
compositions of the user data area and the protected area 
in the file system layer are modified to those shown in 
FIGS. 7 OA and 70B. The user data area shown in FIG. 70A 
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differs from that shown in FIG. 8A in that files named 
"POBXXX.JPG" and "POBXXX.SPl" have been added, in addition 
to the POBManager file "POBOOO.POM". 

The files "POBXXX.JPG" and "POBXXX.SPl" correspond 
5 to the POBs shown in FIG. 69, while the file "POBOOO.POM" 
corresponds to the POBManager. The difference between the 
files "POBXXX.JPG" and "POBXXX.SPl" lies in whether 
copyright protection is necessary. Files with a "JPG" 
filename extension are merely files containing still image 
10 data in JPEG format, while files with an "SPl" filename 
extension have been encrypted to protect the copyrights 
over the still images. Here, "SP" is an abbreviation for 
"Secure Picture" and shows that copyright protection is 
necessary. 

15 Still images such as family photographs or memorial 

pictures taken by users can be recorded onto a flash memory 
card to allow users to personalize the stored content . Since 
copyright protection is generally unnecessary for such 
images, they can be recorded on a flash memory card in JPEG 

20 format without encryption. On the other hand, artist 
photographs and album artwork are generally the property 
of the artist or record label. Since there is the risk of 
users illegally copying images that have been provided by 
an electronic music distribution service, these images are 
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recorded on a flash memory card as "Secure Picture" files. 
The numbers "001", "002", "003", . . . assigned to the 
filenames "POBXXX.SPl" and "POBXXX.JPG" are the POB numbers 
that are assigned to individual picture objects (POBs) • 
5 This means that picture objects (POBs) can be specified 
using POB numbers. 



{69-2_70B-l} Coxnposition of the User Data Area in the File 
10 System Layer 

FIG. 70B shows the composition of the protected area 
in this second embodiment . When compared with the protected 
area shown in FIG. 8B, the protected area in this second 
embodiment further includes an encryption key storing file 

15 named "POBSPl . key" . This file stores the FileKeys used for 
decrypting the (encrypted) files "POBXXX.SPl" . When a file 
"POBXXX.SPl" is read, a FileKey needs to be extracted from 
this encryption key storing file "POBSPl . key" . 

A server computer operated by a record label that uses 

20 electronic music distribution stores the SD_Audio 

directories shown in FIGS. 7 OA and 7 OB. When a user orders 
a music content, the server computer compresses the 
appropriate SD_Audio directory, encrypts it, and then sends 
it to the user who issued the order. 
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The user's computer receives the SD_Audio directory, 
decrypts it, decompresses it, and so obtains the original 
SD_Audio directory. Note that the computer may instead 
download tracks (AOBs) with the accompanying still images 
5 (POBs) from the server computer, and then generate the 
SD-Audio directories shown in FIGS. 70A and 70B by itself 
on the flash memory card 31. 

{69-3_71A,B,C-l} Internal Con?>osition of "POBXXX.JPG" and 
10 "POBXXZ.SPl" Files 

The following describes the internal composition of 
"POBXXX.JPG" and "POBXXX.SPl" files. FIG. 71A shows the 
internal composition of a "POBXXX.JPG" file.. This file 
includes still image data that has not been encrypted, and 
15 so has the same composition as a standard JPEG file. 
FIG. 7 IB shows the internal composition of a 
"POBXXX.SPl" file. As shown in the drawing, such files 
include a POB_Header (POB_H) and encrypted still image data 
in JPEG format. 

20 The broken lines hPl shown in FIG . 7 IB show the internal 

composition of the POB_H . As shown in the drawing, the POB_H 
is composed of a two-byte POB_ID set at the value "FFEO" 
to show the present file is a POB file, a one-byte reserved 
region, a one-byte POB_ATR that shows whether encrypted 
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data is present in the "POBXXX.SPl", and a four-byte POB_SZ 
showing the data size of the POB. 

When encrypted data is present in the file "POBXXX . SPl" , 
the value "0" is set in the POB_ATR to show the "data body 
5 exists" (i.e., the file "POBXXX. SPl" does not make indirect 
reference to another file) . Conversely, when encrypted 
data is not present in the file "POBXXX. SPl", the file will 
instead store the file path of a file including still image 
data (i.e., the file "POBXXX. SPl" indirectly refers to 

10 another file) . FIG. 71C shows an example of a POB file that 
stores a file path instead of an encrypted data body. 

The filename "photo001.JPG" given in the path 
"¥DCIM¥Ctg_001¥photo001. JPG" indicates a file storing 
still image data for a digital photograph taken using a 

15 digital still camera. When a directory path and filename 
are indicated in a POB file in this way, indirect reference 
is made to image data stored in the file "photo001.JPG" 
with the path "¥DCIM¥Ctg_001¥photo001 . JPG" . In this 
"POBXXX. SPl "^ the POB_ATR in the POBManager is set at the 

20 value "1" to show that there is "no data body". 

As one example, when the device driver of a digital 
still camera has a requirement that the still image data 
recorded with the camera is recorded in a particular file 
in a particular directory, a POB file such as that shown 
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in FIG. 71C can specify a JPG file storing still image data 
using an indirect reference file path (in FIG, 71C the device 
driver for the digital still camera requires files to be 
stored with the path "¥DCIM¥Ctg_001¥photo001. JPG" etc.) . 

5 As a result^ even if still image data recorded by the digital 
camera is recorded in a particular file and a particular 
directory in accordance with the needs of a device driver, 
such image data can still be displayed during playback of 
a music content. 

10 This completes the explanation of the presentation 

data in this second embodiment of the present invention. 



{72-1} PlayListManager and TrackManager 

The files "POBXXX.JPG" and "POBXXX.SPl" in the 
15 presentation data are displayed in synchronization with 
the playback of tracks that was described in the first 
embodiment. To achieve such synchronous display of images 
with tracks, the PlaylistManager and TrackManager of the 
second embodiment have the compositions shown in FIG. 72. 
20 FIG. 72 shows the detailed compositions of the 

PlaylistManager and the TrackManager in this second 
embodiment. The PlaylistManager and the TrackManager in 
this embodiment differ from those of the first embodiment 
that were shown in FIG. 17 is that, unlikebefore, the contents 
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Of the Default_Playlist_General_Information (DPLGI) and 
the Playlist_General_Information (PLGI) are clearly shown, 
and that the TKI_POB_ATR and twenty TKI_POB_SRPs are newly 
provided in the TKGI. 

5 

{72-2} DPLGI 

As shown by the broken lines h61^ the 
Default_Playlist_General_Information (DPLGI) includes a 
DPLI_ID field in which a unique identifier for the DPLI 
10 is written, a DPLI_TK_Ns field in which the number of tracks 
referred to by the DPLI is written, a DPLI_PB_TM field in 
which the total playback time of all of the tracks referred 
to by the default playlist is written in millisecond units, 
a DPLI_POB_ATR field, and sixty DPLI_POB_SRP fields. 

15 

{72-3} PLGI 

As shown by the broken lines h62, each piece of 
Playlist_General_Information (PLGI) is composed of a PLI_ID 
field in which a unique identifier for the PLI is written, 
20 a PLI_TK__Ns field in which the number of tracks (where the 
maximum is "99") referred toby the PLI is written, aPLI_PB_TM 
field in which the total playback time of all of the tracks 
referred to by the playlist is written in millisecond units, 
a PLI_POB_ATR field, and twenty PLI_POB_SRP fields. 
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{72-4__73> Overview of the Additions and Improvements made 
in the Second Embodiment 

As can be understood from the preceding explanation, 
5 the TKGI in this second embodiment further includes two 
kinds of information, the TKI_POB_ATR and TKI_POB_SRPs . 
In the same way, the DPLGI further includes two kinds of 
information, the DPLI_P0B_ATR and DPLI_POB_SRPs , and each 
PLGI further includes two kinds of information, the 
10 PLI_POB_ATR and PLI_POB_SRPs . 

The TKI_POB_SRPs , PLI_POB_SRPs , and DPLI_POB_SRPs 
each have the same composition and are used to specify a 
POB. FIG. 73 shows how POB files, such as those shown in 
FIG. 70A, are specified by the TKI_POB_SRPs, PLI_POB_SRPs, 
15 and DPLl_POB_SRPs . The following describes the data 
construction of the TKI_POB_ATR {DPLI_POB_ATR, 
PLI_POB_ATR) and the TKI_POB_SRPs (DPLI_POB_SRPs, 
PLI_POB_SRPs) . 

20 {74-1) TKI_POB_SRPs 

A TKI_POB_SRP is a field that specifies a POB to be 
displayed during the playback period of a specific AOB, 
out of the entire playback period of the tracks indicated 
in order for playback by the Def ault_Playlist_Information 
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or a PLI. In other words, by setting the TKI_POB_SRP in 
the TrackManager, a POB to be displayed during a track can 
be specified. 

FIG . 7 4 shows the data construction of the TKI_POB_SRPs 
5 and TKI_POB_ATR. 

As shown in the drawing, a TKI_POB_SRP is composed 
of a "POB specifying field" (shown as the "POB_No," in the 
drawing) between the bit number b25 and the bit number bl6, 
a "Number Of Pixels" field between the bit number bll and 
10 the bit number b8, a "Huffman Table" field between the bit 
number b7 and the bit number b6, a "Chrominance Sampling" 
field between the bit number b5 and the bit number b4, and 
a "Picture Coding Mode" field between the bit number b3 
and the bit number bO. The fields between the bit number 
15 bl2 and the bit number bl5 and between the bit number b26 
and the bit number b31 are reserved regions. 

The "POB specifying field" is used for storing a number 
between "1" and "999" as the number of the POB to be displayed 
during the playback period of the AOB file corresponding 
20 to this TKI . When no still image is to be displayed during 
the playback period of the AOB file corresponding to this 
TKI, the "POB specifying field" is set at "0". 

The "Picture Coding Mode" is a field that is used to 
inform a playback apparatus of the encoding method used 
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for the still image specified by the "POB Specifying Field" . 

The "Chrominance Sampling" field is used to show the 
ratio used for the luminance sampling and the chrominance 
sampling of two colors when the still image specified by 

5 the "POB Specifying Field" was encoded. The binary value 
"00" is set in this field to indicate the ratio is "4:2:2", 
while the value "01" is set to indicate the ratio is "4 :2: 0" • 
The "Huffman Table" field shows whether a typical 
Huffman table should be used when displaying the still image 

10 specified by the "POB Specifying Field" . This field is set 
at "00" when a Huffman table should be used. 

The "Number Of Pixels" field is a field in which the 
size of the still image specified by the "POB specifying 
field" is written in pixels. The binary value "0000" is 

15 written in this field when the still image specified by 
the "POB Specifying Field" is 96*96 pixels, the "0001" is 
written when the image is 640*480 pixels, and the value 
"0010" is written when the image is another size that is 
in a range of 160*120 pixels to 1800*1200 pixels. 

20 The TKGI includes twenty TKI_POB_SRPs with this 

construction^ so that a maximum of twenty still images can 
be displayed during the playback of a track. When a track 
is composed of several TKIs, only the TKI_POB_SRPs in the 
first TKI are valid. 
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{74-2} TKI_POB_ATR 

The "TKI_POB_ATR" is provided to specify how the POBs 
specified by the twenty TKI_POB_SRPs in a TKGI should be 
5 displayed. The "TKI_POB_ATR" includes a "Display Order 
Mode" between bit number bO and bit number bl and a "Display 
Timing Mode" between bit number b2 and bit number b3. 

The "Display Order Mode" field is set to show the order 
in which the POBs specified by the twenty TKI_POB_SRPs in 
10 a TKGI are to be displayed. In this embodiment, POBs are 
displayed in one of three modes during the playback period 
of an AOB. 

The first mode is called "Sequential Mode" and is where 
the POBs specified by a maximum of twenty TKI_POB_SRPs in 
15 a TKGI are displayed in the order in which the TKI_POB_SRPs 
are given in the TKGI. 

The second mode is called "Random Mode" and is where 
the POBs specified by a maximum of twenty TKI_POB_SRPs in 
a TKGI are displayed in a random order. 
20 The third mode is called "Shuffle Mode" and is where 

the POBs specified by a maximum of twenty TKI_POB_SRPs in 
a TKGI are displayed in a random order without repetition. 

To indicate sequential mode, the binary value "00" 
is set in the "Display Order Mode" field. Conversely, the 
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binary value "01" is set to indicate random mode and the 
binary value "10" is set to indicate shuffle mode. 

The "Display Timing Mode" field is set to show whether 
the display of POBs specified by a maximum of twenty 
5 TKI_POB_SRPs in a TKGI should be synchronized with the 
playback of the AOB file corresponding to the TKI . The mode 
where images are synchronized with audio is called 
"Slideshow Mode". During "Slideshow Mode", the user is 
unable to skip through the images being displayed without 

10 skipping through the audio being played back. 

On the other hand, the mode where images and audio 
are not synchronized is called "Browser Mode". In browser 
mode, the user can skip through images without skipping 
through the audio. 

15 In this way, information showing which POBs should 

be displayed during the playback of the corresponding AOB 
file, in what order such POBs shouldbe displayed, and whether 
display of POBs should be synchronized with the playback 
of the corresponding AOB file is set in a TGKI. 

20 

{74-3_75} Exasrple Setting of the TKI_POB_SRPs included in 
TRI#1 to TKI#3 

FIG. 75 shows an example setting of the TKI_POB_SRPs 
for TKI#1 to TKI#3 included in the TrackManager . 
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The first level in FIG, 75 shows the TrackManager, 
while the second level shows nine POB files. The 
TrackManager on the first level includes eight TKIs, with 
the arrows showing which POB files are referred to by the 
5 TKI_POB__SRPs in these eight TKIs. 

As shown by the arrows, TKItl includes three 
TKI_POB_SRPs that specify POBOOl to POB003, TKI#2 includes 
three TKI__POB_SRPs that specify POB004 to POB006 and TKI#3 
includes three TKI_POB_SRPs that specify POB007 to POB009. 

10 In this embodiment, POBOOl to POB009 are assumed to 

JPEG image data composed of song lyrics arranged onto a 
plain background. The words composing the lyrics are shown 
using a suitable font for the mood of the song and can be 
subject to embellishments, such as the addition of bold 

15 outlines. 

The lowest level in FIG. 75 shows the content of each 
POB . The content of POBOOl to POB003 is the lyrics for TrackA, 
the content of POB004 to POB006 is the lyrics for TrackB, 
and the content of POB007 to POB009 is the lyrics for TrackC. 
20 Since these images will be meaningless unless they are 
displayed during the playback of the corresponding tracks, 
the TKI_POB_SRPs included in the TKIs are set so that these 
images are displayed during such playback. 

The playback period of each track is the same as in 
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FIG. 16 that was referred to in the first embodiment. This 
means that the playback period of "AOBOOl . SAl " corresponding 
toTKI#lis e.lminutes, the playback period of "AOB002.SA1" 
corresponding to TKI#2 is 3.3 minutes, and the playback 
5 period of "AOB003 . SAl" corresponding to TKI#3 is 5 . 5 minutes . 
During these playback periods, the TKI_POB_SRPs given in 
the TKIs will become valid, so that a playback apparatus 
can display POBs in accordance with these valid 
TKI_POB_SRPs . 

10 The playback period of "AOBSAl • 001" corresponding to 

TKI#1 is 6.1 minutes, so that if POBOOl to POB003 are to 
be displayed for the same time during this period, each 
image will be displayed for 2.03 (=6.1/3) minutes. .The 
playback period of "AOBSA2.001" corresponding to TKI#2 is 

15 3.3 minutes^ so that POB004 to POB006 will each be displayed 
for 1.1 (=3.3/3) minutes. The playback period of 
"AOBSA3.001" corresponding to TKI#3 is 5. 5 minutes, so that 
POB007 to POB009 will each be displayed for 1.83 (=5.5/3) 
minutes. 

20 

{74-4 76} Example Setting of the TKI_POB_SRPs Included in 
TKI»4 to TKI#8 

FIG. 7 6 shows one example of the setting of the 
TKI_POB_SRPs in TKI#4 to TKI#8 included in the TrackManager . 
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The first level shows the TrackManager, while the second 
level shows ten POB files. As shown by the arrows in the 
drawing, TKI#4 includes seven TKI_POB_SRPs that 
respectively specify POBOlO to POB016. 

5 In the same way, TKI#8 includes three TKI_POB_SRPs 

that specify POB017 to POB019. In the present embodiment, 
POBOlO to POB019, like POBOOl to POB009, are JPEG image 
data composed of song lyrics arranged onto a plain background . 
The reason that TKI_POB_SRPs are only set for TKI#4 and 

10 not for any of TKI#5 to TKI#7 is that when a single track 
is composed of a plurality of TKIs, only the TKI_POB_SRPs 
in the first TKI are valid, as stated earlier. 

The content of POBOlO to POB016 is the lyrics for TrackD . 
that is shown in FIG. 16 of the first embodiment, while 

15 the content of POB017 to POB019 is the lyrics for TrackE. 
The total playback period of "AOB004.SA1" to "AOB007.SA1" 
corresponding to TKI#4 to TKI#7 is 30.6 minutes, so that 
the display period of each of POBOlO to POB016 is 4.37 
(=30.6/7) minutes. As a result, each POB can be displayed 

20 for the same period during the playback period of TrackD. 
Since the playback period of "A0BSA8.SA1" corresponding 
to TKI#8 is 7 . 0 minutes , the display period of each of POB017 
to POB019 is 2.33 (=7.0/3) minutes. 
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{77-1} DPLI_POB_SRP and DPLI_POB_ATR included in the DPLGI 

While the TKI_POB_SRPs can specify which POBs are to 
be displayed during which track, the DPLI_POB_SRPs given 
in the DPLGI specify the POBs that should be displayed during 

5 the playback period of a plurality of AOBs in accordance 
with the order specified by the 
Def ault_Playlist_Inf ormation . 

FIG. 77 shows the DPLI_POB_SRPs and DPLI_POB_ATRs 
included in the DPLGI. As can be seen from this drawing, 

10 the DPLI_POB_SRPs and DPLI_POB_ATRs included in the DPLGI 
have the same data constructions as the TKI_POB_SRPs and 
TKI_POB_ATRs . 

Since the Def ault_Playlist_Inf ormation sets the 
playback order for a plurality of AOB files, the 

15 DPLI_POB_SRPs and DPLI_POB_ATRs given in FIG. 77 can be 
set to show (1) which POBs should be displayed during the 
playback period of the plurality of AOB files indicated 
by the playback order in the Def ault_Playback_Inf ormation, 
(2) in what order such POBs should be displayed, and (3) 

20 whether the display of POBs is to be synchronized with the 
playback of the AOB corresponding to the TKIs. 

{77-2_78} Exan^le Setting of Twenty DPLI_POB_SRPs 

FIG. 78 shows an example setting of twenty 
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DPLI_POB_SRPs included in the 

Default_Playlist_Information. The first level in the 
drawing shows the Default_Playlist_Information, with the 
inner frames showing the DPLGI and twenty DPLI_POB_SRPs . 
5 The second level shows the twenty POB files POB020 to POB039, 
As shown by the arrows, the twenty DPLI_POB_SRPs 
respectively specify the twenty POB files POB020 to POB039. 

POB020 is an image used as the jacket image for the 
packaged version of the music album composed of TrackA to 

10 TrackE, while POB021 is a logo of the production company 
that produced this music album. POB022 to POB025 are artist 
photos, POB026 to POB031 are images taken from a promotional 
. (promo) video, and POB032 to POB039 are photos of the artist 
performing TrackA to TrackE during a concert. 

15 The DPLI_POB_SRPs in the Def ault_Playlist_Inf ormation are 
defined by the producer of the music contents, and so can 
be set so as to have images for the tracks represented by 
the music contents, artist photos, etc. displayed during 
playback. 

20 During the playback period of the AOB files specified 

by the playback order in the Default_Playlist_Inf ormation, 
the POB files specified by the DPLI_POB_SRPs included in 
the DPLGI will be displayed. For the example shown in FIG. 
40, the Default_Playlist_Information specifies a playback 
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order for the five tracks TrackA to TrackE via the eight 
TKIs composing these tracks. Meanwhile, in the example 
shown in FIG. 78, the DPLI_POB_SRPs included in this 
Default_Playlist_Information specify twenty POB files, 
5 with these specifications being valid during the 52 . 5-minute 
playback period of TrackA to TrackE . When this 52 . 5-minute 
playback period is to be divided equally among the POB020 
to POB039, each image will be displayed for 2 . 625 (=52 . 5/20) 
minutes . 

10 

(77-3__79) Changes in the Foreground and Background Zaaages 
as Playback Progresses 

FIG. 79 is a timing chart showing what images are 
combined when the POBs specified by the DPLI_POB_SRPs 

15 included in the Default_Playlist_Information are used as 
background images and the POBs indicated by the TKI_POB_SRPs 
included in the TrackManager are used as foreground images . 

The first level in the drawing shows the same POBs 
as the second level in FIG. 78, while the second level shows 

20 the same POBs as the second level in FIGS. 75 and 76. The 
scale that extends horizontally across the top of FIG. 79 
shows the playback time in units of one minute. The 
horizontal width of each POB in FIG. 79 therefore shows 
the continuous display time for each POB. 
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By referring to the time scale in FIG. 79, it can be 
seen that during the period from the start of playback the 
point at 6, Iminutes, POBOOl to POB003 (the lyrics forTrackA) 
are displayed are successively displayed as the foreground 
5 image, while POB020 (the jacket image), POB021 (the 
production company logo) , and POB022 (an artist photo) are 
successively displayed as the background image. 

In the playback period between the point 6.1 minutes 
after the start of playback and the point 14.9 (=6 . 1+3 . 3+5 .5) 
10 minutes after the start, POB004 to POB009 (the lyrics to 
TrackB and TrackC) are successively displayed as foreground 
images while POB022 to POB025 (artist photos) are 
successively displayed as background images. 

In the period following the point 14.9 minutes from 
15 the start of playback, POBOlO to POBOll (the lyrics for 
TrackD) are successively displayed as foreground images 
while POB026 to POB028 (images taken from a promo video) 
are successively displayed as the background image. 

20 {77-4_80) 

In the timing chart in FIG. 79, a combined image 
composed of POB004 (the lyrics to TrackB) in the foreground 
and POB022 (an artist photo) in the background will be 
displayed starting from the point 6.1 minutes after the 
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Start of playback according to the 

Default_Playlist_Information, FIG. 80 shows how the 
foreground image and background image are combined at this 
point 6.1 minutes after the start of playback according 
5 to the Default_Playlist_Information. 

{77-5_81) 

In the same way, a combined image composed of POBOlO 
(the lyrics to TrackD) in the foreground and POB026 (a shot 

10 from a promo video) in the background will be displayed 
starting from the point 16minutes after the start of playback 
according to the Def ault_Playlist_Inf ormation. FIG. 81 
shows how the foreground image and background image are 
combined at this point 16 minutes after the start of playback 

15 according to the Default_Playlist_Information. 

As described above, if a combined image is produced 
by combining a POB file specified by a DPLI_POB_SRP in the 
Default__Playlist_Information as the foreground image and 
a POB file specified by a TKI_POB_SRP in the 

20 Default_Playlist_Information as the background image, the 
lyrics to the track being played back can be displayed with 
an artist photo, an image from the promo video of the track, 
a concert photo, or the like . The settings of what POB files 
should be displayed at what time can also be easily changed 
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by rewriting the TKI_POB_SRPs and DPLI_POB_SRPs in the 
TrackManager and Default_Playlist_Information. 

{82-1} PLI_POB__SRPs and PLI_POB_ATR in a PLGI 

5 The PLI_POB_SRPs and PLI_POB_ATR included in a PLGI 

have the same data constructions as the DPLI_POB_SRPs and 
DPLI_POB_ATR included in the DPLGI, and as the TKI_POB_SRPs 
and TKI_POB_ATR in a TKI. FIG. 82 shows the PLI_POB_SRPs 
and PLI_POB_ATRs included in a PLGI. 

10 As in the first embodiment, a PLI differs from the 
Default_Playlist_Information in that it shows a 
user-defined playback order, so that the PLI_POB_SRPs and 
PLI_POB_ATR show which POBs should be displayed during the 
playback of the plurality of AOB files specified in this 

15 user-defined playback order, in what order such POBs should 
be displayed, and whether display of POBs should be 
synchronized with the playback of the corresponding AOB 
files. Note that while the PLI_POB_SRPs in the 
Default_Playlist_Information were described as being set 

20 by the producer of the music contents, these DPLI_POB_SRPs 
may be freely set by users. 
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{82-2_83} Example Settings of the PLI_POB_SRPs included 
in a PLI 

The following describes example settings of the 
PLI_POB_SRPs included in a PLI. 
5 FIG. 83 shows one example of the settings of twenty 

PLI_POB_SRPs in a PLI . The first level in the drawing shows 
a PLI, with the inner frames showing the PLGI and twenty 
PLI_POB_SRPs . The second level shows the twenty POB files 
POB040 to POB059. As shown by the arrows, the twenty 

10 PLI_POB_SRPs respectively specify the twenty POB files 
POB040 to POB059. 

While POB020 to POB039 are still image data that is 
provided by the producer of the music contents, POB040 to 
POB059 are still image data for personal photos provided 

15 by the user. As examples, POB040 is a photo of the user's 
family, while POB041 is a photo of the user's graduation 
ceremony, POB042 to POB051 are photos of the user's pet, 
POB04 6 to POB051 are holiday snaps from the user's trip 
to Europe, and POB052 to POB059 are holiday snaps from the 

20 user's trip to the USA. To simplify the explanation, the 
total playback period of the AOB files specified by this 
PLI and the number of POBs specified for display by this 
PLI are the same as the Def ault_Playlist_Inf ormation . This 
means that the total playback period of TrackA to TrackE 
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specified by this PLI is 52.5 minutes , and that the display 
period for each of POB040 to POB059 will be 2 . 625 (=52 . 5/20) 
minutes if each image is to be displayed for the same time 
during this playback period. 

5 

{82-3_^84) Changes in the Foreground and Background Images 
as Playback Progresses 

FIG. 84 is a timing chart showing what images are 
combined when the POBs specified by the PLI_POB_SRPs 

10 included in the Playlist_Inf ormation described above are 
used as background images and the POBs indicated by the 
TKI_POB__SRPs included in the TrackManager are used as 
foreground images. 

The first level in the drawing shows the same POBs 

15 as the second level in FIG. 83, while the second level shows 
the same POBs as the second level in FIGS. 75 and 76. The 
scale that extends horizontally across the top of FIG. 84 
shows the playback time in units of one minute. The 
horizontal width of each POB in FIG. 84 therefore shows 

20 the continuous display time for each POB. 

By referring to the time scale in FIG. 79, it can be 
seen that during the period from the start of playback to 
the point at 6.1 minutes, POBOOl to POB003 (the lyrics for 
TrackA) are displayed are successively displayed as the 
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foreground image, while POB040 (a family photo) , POB041 
(a graduation photo) , and POB042 (a pet photo) are 
successively displayed as the background image. 

In the playback period between the point 6,1 minute 
5 after the start of playback and the point 14 . 9 minutes after 
the start, POB004 to POB009 (the lyrics to TrackB and TrackC) 
are successively displayed as foreground images while POB042 
to POB045 (pet photos) are successively displayed as 
background images. 

10 In the period following the point 14.9 minutes from 

the start of playback, POBOlO to POBOll (the lyrics for 
TrackD) are successively displayed as foreground images 
while POB045, and POB04 6 to POB04 8 (holiday snaps of European 
holiday) are successively displayed as the background image . 

15 In this way, while the POBs specified by the 

Def ault_Playlist_Inf ormation are chosen by the record label 
that produces the music contents and so generally correspond 
to artist images and images related to the music contents, 
the POBs specified by a PLI can be freely selected by the 

20 user and so can have a high personal value. 

{82-4_85) 

In the timing chart in FIG. 84, a combined image 
composed of POB004 (the lyrics to TrackB) in the foreground 
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and POB042 (a pet photo) in the background will be displayed 
starting from the point 6,1 minutes after the start of 
playback according to the Playlist_Information described 
above. FIG. 85 shows how the foreground image and background 
5 image are combined at this point 6 . 1 minutes after the start 
of playback according to this Playlist_Information. 

{82-5_86> 

In the same way, a combined image composed of POBOlO 
10 (the lyrics to TrackD) in the foreground and POBO 4 6 (a holiday 
snap from Europe) in the background will be displayed 
starting from the point 16minutes after the start of playback 
according to this Playlist_Information. FIG. 86 shows how 
the foreground image and background image are combined at 
15 this point 16 minutes after the start of playback according 
to this Playlist_Information. The song lyrics that form 
part of these combined images are the same as in FIGS. 80 
and 81, though since the background images are different, 
the combined images in FIGS. 85 and 86 give a completely 
20 different impression to those in FIGS. 80 and 81. 

As described above the PLI_POB_SRPs in a PLI defined 
by the user himself /herself can specify POB files that differ 
from those specified by the Default_Playlist__Inf ormation, 
so that the user can have his/her favorite images displayed 
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during the playback of his/her favorite tracks. 

{82'-6_87} Example Setting of the Same POBs in the 
DPLI_POB_SRPs in the Default_Playlist_Inf ormation 

5 In the examples in FIGS. 78, 79, 82, and 83, all of 

the DPLI_POB_SRPs included in the 

Default_Playlist_Information specify different POB files, 
though it is possible for two or more DPLI_POB_SRPs in the 
Default_Playlist_lnformation to specify the same POB file. 

10 By doing so, the same POB file can be displayed during the 
playback period of a plurality of tracks , making it possible 
to reduce the number of POB files that need to be provided 
by the title producer. This reduces the time and cost 
required to produce a title. 

15 FIG. 87 shows one example where the number of POB files 

is reduced by having some of the DPLI_POB_SRPs in the 
Default_Playlist_Inf ormation specify the same POB file. 
In this drawing, both DPLI_P0B_SRP#1 and DPLI_P0B__SRP#4 
specify POB020, while both DPLI_P0B_SRP#2 and 

20 DPLI_P0B_SRP#5 specify POB021. 

{82-7_88) Changes in the Foreground and Background Images 
as Playback Progresses 

FIG. 88 is a timing chart showing what images are 
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combined when the POBs specified by the DPLI_POB_SRPs 
included in the Def ault_Playlist_Information described 
above are used as background images and the POBs indicated 
by the TKI_POB_SRPs included in the TrackManager are used 

5 as foreground images. 

As can be seen from this timing chart, POB020 that 
shows the jacket image of the packaged product is displayed 
a total of three times that are at the start of playback, 
7 . 875 minutes after the start of playback, and 15.75 minutes 

10 after the start of playback. In the same way, POB021 that 
shows the logo of the record label is displayed a total 
of three times that are 2,625 minutes, 10.5 minutes, and 
18.375 minutes after the start of playback. When the 
DPLI_POB_SRPs are set as shown in FIG. 87, the same POB 

15 is repeatedly displayed, so that reusable images such as 
the jacket image or record label logo can be repeatedly 
displayed - 

This completes the explanation of the TGKI, DPLGI, 
and PLGIs. 

20 

{69-4_89} POBMG 

The following describes the POBManager (POBMGs) that 
is newly provided in the navigation information in the second 
embodiment. FIG. 89 shows the composition of the POBMG. 
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As shown in the drawing, a POBMG is composed of POB Management 
Information (POBMGI) and POB Count Information (P0BCI)#1, 
#2 . . . #n. 

5 {69-4_89-l) POBMGI 

As shown by the broken lines in FIG, 89, the POB 
management information (POBMGI) includes POBMGI 
identification information that occupies the 0th and 1st 
bytes, a reserved field that occupies the 2nd and 3rd fields, 

10 a POB_Ns field that occupies the 4th and 5th fields, and 
a reserved field that occupies the 6th and 7th fields. 

An ID (a character set code "A6" according to IS0646) 
that identifies the POBMGI is written in the POBMGI 
identification information field. A number of POBs in a 

15 range from "0" to "999" is written in the POB_Ns field. 
This completes the explanation of the POBMGI, 

{69-4_89-2} POBCI 

The following describes the POB Count Information 
20 (POBCI) . The POB Count Information is management 

information that is provided separately for each POB. The 
bit construction of the POB Count Information is as shown 
by the broken lines in FIG. 89. That is, the POB Count 
Information includes a POB_RCN field that occupies the 
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region from bit number bO to bit number b9, a reserved field 
that occupies the regions from bit number blO to bl3, and 
a data existence field that occupies the region from bit 
number bl4 to bit number bl5. 

5 

{69-4_89-3) POB_RCN 

The "POB^RCN" field shows whether the display of a 
POB corresponding to a POBCI is specified by the DPLGI, 
a PLGI, or a TKGI, When the corresponding POB is specified, 

10 the number of specifications, that is, the number of TKIs 
specifying the POB for display, is written as a number in 
the range "1" to "999". 

As in the first embodiment, TKIs can be deleted so 
that the settings in the Def ault_Playlist_Information and 

15 the Playlist_Information can be freely changed by users. 
When one or more TKIs that specify a particular POB are 
deleted, the POB reference count for that POB has to be 
decremented in accordance with the number of specifying 
TKIs that have been deleted. Also, when the 

20 Default_Playlist_Inf ormation or a PLI is deleted, the 
POB_RCN has to be decremented by the number of specifying 
TKIs that have been deleted. 

When a POB is not specified by the DPLGI, a PLGI, or 
the TKGI, the POB_ref erence_count is set at "0". As a POB 
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whose POB_reference__count is "0" is not referred to by a 
TKI or a playlist, on deleting a TKI or playlist, a playback 
apparatus can detect POBs whose reference_count_number 
becomes zero and delete the POB files storing such POBs 
5 to reduce the amount of still image data recorded in the 
flash memory card. 

When certain POBs have a strong relationship with 
certain tracks and such POBs will be meaningless if not 
displayed during the playback of the related tracks, such 
10 POBs can be deleted when their ref erence_count_number 
becomes zero to avoid wasteful usage of the storage capacity 
of the flash memory card. This could apply to the case of 
POBs showing song lyrics for tracks recorded in the flash 
memory card. 

15 Apart from when one or more TKIs are deleted, when 

a POB specified by a DPLI_POB_SRP, a PLI_POB_SRP, and/or 
a TKI_POB_SRP is deleted by an editing operation, the 
reference_count_number may be decremented in the same way. 

20 {69-4_89-4) Data Existence 

The data existence field that occupies bit nxomber bl4 
and bit number bl5 is set to indicate whether a POB that 
corresponds to the present POB number exists. The binary 
value "01" is set in this field when a corresponding POB 
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exists, while the value "00" is set when there is no such 
POB, Here, data is said to "exist" when data with intrinsic 
value is present. 

When this field indicates that a POB exists and the 
5 deletion of a TKI or PLI has resulted in the 

POB_reference_count reaching "0", a playback apparatus will 
judge that the POB corresponding to the "0" 
POB_ref erence_count should be kept and so will not delete 
the POB. 

10 If a POB has intrinsic value regardless of whether 

it is referred to by a TKI or a PLI, the data existence 
field corresponding to this POB can be set at "1" • By setting 
the data existence field corresponding to POBs that are 
only of value if they are referred to by a TKI or a playlist 

15 at "0", it becomes possible to selectively keep only POBs 
with intrinsic value on the flash memory card. POBs that 
are only meaningful when displayed together with the 
playback of a track (i.e., POBs that have no intrinsic value) 
can be deleted when the corresponding track is deleted, 

20 enabling the storage capacity of the flash memory card to 
be used efficiently. 

This completes the explanation of the POBManager 
(POBMG) . 
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(69-5} Updating that Accostpanies the Editing of TKIs 

The following describes how the TKI_POB_SRPs and the 
DPLI_POB_SRPs are updated in the following five cases . The 
first four cases are the same as in the first embodiment, 
5 so that in the first case (easel), a track is deleted. In 
the second case (case2) a track is deleted and a new track 
is recorded. In the third case (case3) two out of a plurality 
of tracks are selected and combined into a single track. 
In the fourth case (case4) , one track is divided to produce 
10 two tracks. In the fifth case (caseS) , the playback order 
of tracks is changed. 

In easel where a track is deleted, each TKI 
.corresponding to the track is set at "Unused" and the 
TKI_POB_SRPs in each TKI are deleted. At the same time, 
15 the POB_reference_count in the POBManager of the POBs 
specified by these TKI_POB_SRPs are decremented • POBs that 
are specified by PLI_POB_SRPs and/or DPLI_POB_SRPs in the 
DPLGI or a PLGI are unaffected by this deletion. 

When the DPL_TK_SRPs are changed so as to specify the 
20 tracks in a different order (caseS) , the playback order 
of tracks will change, so that the display order of the 
POBs specified by the TKI_POB_SRPs will also change. 

In case3, it is preferable for the TKI_POB_SRPs in 
the TKIs to also be combined. This is because only the 
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. TKI_POB_SRPs in a first TKI are valid for a track composed 
of a plurality of TKIs. When a track combining operation 
is performed, the POBs specified by the TKI_POB_SRPs of 
the latter TKI will need to be specified by TKI_POB_SRPs 
5 in the former TKI. 

When a track is divided (case4), it is necessary to 
change the TKI_BLK_ATR of the track and to divide the TKTMSRT 
and BIT as described in the first embodiment. In addition, 
the TKI_POB_SRPs specified in the TKGI also need to be divided 
10 into two groups that are respectively assigned to the former 
TKI and to the extra TKI that is newly produced by the 
division. 

{69-6} Actual Example of How the TKI_POB_SRPs and 
IS DPLI_POB_SRPs May Be Used 

As described above, the data constructions of the 
TrackManager and PlaylistManager allow the user to freely 
change the relationship between AOB files and POBs by 
changing the settings of the TKI_POB_SRPs , DPLI_POB_SRPs , 
20 and PLI_POB_SRPs . This means that a producer of music 
contents can provide music contents with differing amounts 
of still image data to consumers, such as tracks with lyrics, 
tracks with no lyrics, and tracks with lyrics and background 
images. Of course, the producer may charge different 
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amounts for these different types of contents. 

When a consumer wishes to buy tracks without the lyrics , 
the producer may produce an SD_Audio directory that includes 
the eight AOBs shown in the first embodiment and a 
5 TrackManager where the TKI_POB_SRPs in TKI#1 to TKI#8 
specify POB020 to POB039 as shown in FIG. 78. The producer 
then compresses this directory, encrypts it, and transmits 
it to the consumer's personal computer. Note that the 
consumer's personal computer can instead download tracks 

10 (AOBs) and still images (POBs) corresponding to the tracks 
from a server computer operated by the record label and 
generate the SD-Audio directory shown in FIGS. 70A and 70B 
on the flash memory card 31. 

When the consumer wishes to buy tracks with the lyrics, 

15 the producer may produce an SD_Audio directory that includes 
the eight AOBs shown in the first embodiment and a 
TrackManager where the TKI_POB_S,RPs in TKI#1 to TKI#8 
specify POBOOl to POB019 shown in FIGS. 75 and 76 
corresponding to the lyrics. The producer then compresses 

20 this directory, encrypts it, and transmits it to the 
consumer's personal computer. 

When the consumer wishes to buy tracks with both the 
lyrics and the background images, the producer may produce 
an SD_Audio directory that includes the eight AOBs shown 
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in the first embodiment, a TrackManager where the 
TKI_POB_SRPs in TKI#1 to TKI#8 specify POBOOl to POB019 
shown in FIGS. 75 and 76 corresponding to the lyrics, and 
a Playlist Manager where the DPLI_POB_SRPs specify POB020 

5 to POB039 shown in FIG. 78. The producer then compresses 
this directory, encrypts it, and trOansmits it to the 
consumer's personal computer. Since still image data can 
be freely associated with audio data by setting the 
TKI_POB_SRPs, DPLI_POB_SRPs, and PLI_POB_SRPs in the 

10 present embodiment, music contents can be easily produced 
with different prices in accordance with the amount of 
associated still image data. 



{90-l_91} Playback Apparatus for the Second Embodiment 

15 The following describes a playback apparatus for the 

second embodiment. This playback apparatus differs from 
the playback apparatus described in the first embodiment 
in that while the playback apparatus in the first embodiment 
is portable, the playback apparatus in the second embodiment 

20 is designed for installation as a car stereo. 

FIG. 90 shows how the playback apparatus of the second 
embodiment is used, while FIG. 91 shows the external 
appearance of just the playback apparatus. 

The playback apparatus of this second embodiment 
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differs from the playback apparatus of the first embodiment 
in that it is installed in an automobile as shown in FIG. 
90, in that it includes a large LCD panel 5, and in that 
it is connected to car speakers. Due to the provision of 

5 the large LCD panel 5, the playback apparatus of this second 
embodiment is well suited to the display of the various 
types of still image data mentioned above. 

A second difference with the playback apparatus of 
the first embodiment is that the playback apparatus of the 

10 second embodiment has a descrambler 7 that is capable of 
decrypting encrypted POBs as well as encrypted audio data. 
When a POB has been encrypted and is stored as a POB file 
with a "POBXXX.SPl" filename, a FileKey stored in a Key 
Entry in the encrypted key storing file "POBSPl.KEY" is 

15 set in the descrambler 7 which then decrypts the file 
"POBXXX.SPl". 

A third difference with the playback apparatus of the 
first embodiment is that the playback apparatus of the second 
embodiment stores a program including the processing 

20 required to display POBs as foreground or background images . 
The CPU 10 in this playback apparatus executes this program 
to display images. 
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{90-2_92_93_94} 

The following describes the composition of the 
playback apparatus in this second embodiment. The 
composition of the playback apparatus shown in FIG. 92 
5 differs from the composition of the playback apparatus of 
the first embodiment in that it includes a plurality of 
VRAMs 61. 

The plurality of VRAMs 61 respectively correspond to 
the single graphics planes (layers) . The VRAM for a graphics 
10 plan has transparency Of set in the range 0 to 100% for each 
pixel. The image that is to be displayed on the first LCD 
panel 5 is calculated according to the equation given below. 
FIG. 93A shows how the still images stored in the plurality 
of VRAMs 61 are combined. 

15 

Equation 

Pixel Value of Each Pixel = 

Pixel Value in Graphics Plane 0*(l-af) 
+ Pixel Value in Graphics Plane 1*0? 

20 

The transparency a is set at 0% for the parts of the 
foreground image corresponding to the characters showing 
the lyrics. As a result, parts of the background image that 
positionally correspond to the character strings showing 
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the lyrics are completely hidden. Conversely, the 
transparency (X is set at 100% for the parts of the foreground 
image corresponding to plain background of the lyrics. 
This means that the combined image has the character strings 
5 showing the lyrics in graphics plane 0 displayed on top 
of the background image in graphics plane 1. 

By setting the transparency in this way, it is possible 
to produce a combined image where a lyrics sheet is laid 
on top of a background image, as shown in FIGS, 80 and 81 • 
10 Note that a combined image can be produced in other ways 
aside from that shown in FIG. 93A. As one example, the lyrics 
may be arranged into the lower part of the screen, with 
the background image being shown in the upper part, as shown 
in FIG. 93B. 

15 

{94-1} Flowchart of the Foreground Image Display Procedure 

FIG. 94 is a flowchart showing the foreground image 
display procedure . When playback starts according to TKI#2 
specified by the Def ault_Playlist_Inf ormation, in step S402 
20 the CPU 10 judges whether the TKI_POB_SRPs included in the 
TKGIs in TKI#z specify any POBs. When the TKI_POB_SRPs 
specify one or more POB files, the processing advances to 
step S403 where the CPU 10 counts the number of POB files 
that are specified by the TKI_POB_SRPs included in the TKGI . 
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In step S404, the CPU 10 calculates the display time 
"POB^time" showing the display period to be used for each 
FOB file . After this, in step S405 refers to the TKI_POB_ATR 
in the TKGI and determines the display mode to be used for 

5 displaying the POB files. When the TKI_POB_ATR shows 
sequential mode, the processing advances from step S405 
to step S406, where the variable i is initialized, and to 
step S4 07 , where the POB file specified by the i^^ TKI_POB_SRP 
is displayed for the display time POB_time. 

10 At this point, when the extension of the POB file 

specified by the TKI_POB_SRP is "JPG", the POB is displayed 
as it is. Conversely, when the extension of the POB file 
specified by the TKI_POB_SRP is "SPl", the POB file will 
be in an encrypted state, so that the CPU 10 reads the FileKey 

15 corresponding to the POB file from the protected area, 
decrypts the POB file using the encryption key, and displays 
the POB. 

After this, in step S408 the CPU 10 judges whether 
the variable i has reached the value given in POB_Ns . If 
20 not, the processing proceeds to step S409, where the variable 
i is incremented, and then returns to step S407. 
The processing in steps S406 to S409 is hereafter repeated 
until the variable i reaches the value given in POB_Ns. 
As a result, the POBs specified by the TKI_POB_SRPs in the 
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TKGI are sequentially displayed. When the variable i 
reaches the value given in POB_Ns, the processing in this 
flowchart ends. 

When the TKI_POB_ATR shows random mode, the processing 

5 advances from step S405 to step S410, where the variable 
i is initialized^ and to step S411, where the CPU 10 generates 
a random number r in a range from 1 to POB_Ns . In step S412 
the POB file specified by the r^^ TKI_POB_SRP corresponding 
to the random number r is displayed for the display time 

10 POB_time determined in step S404. 

After this, in step S413 the CPU 10 judges whether 
the variable i has reached the value given in POB_Ns. If 
not, the processing proceeds tostepS414, where the variable 
i is incremented, and then returns to istep S411. In step 

15 S411, the CPU 10 generates another random number r in a 
range from 1 to POB_Ns, and the processing proceeds again 
to step S412, where the CPU 10 reads the POB file specified 
by the r^*" TKI_POB_SRP corresponding to the random number 
r and displays it for the display time POB_time determined 

20 in step S404 . 

As described above, when the extension of the POB file 
specified by the TKI_POB_SRP is "JPG", the POB is displayed 
as it is. Conversely, when the extension of the POB file 
specified by the TKI_POB_SRP is "SPl", the POB file will 
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be in an encrypted state, so that the CPU 10 reads the FileKey 
corresponding to the POB file from the protected area, 
decrypts the POB file using the encryption key, and displays 
the POB, 

The processing in steps S411 to S414 is hereafter 
repeated until the variable i reaches the value given in 
POB_Ns. As a result POBs specified by the TKI_POB_SRPs in 
the TKGI are displayed one after another in a random order. 
When the variable i reaches the value given in POB_Ns, the 
processing in this flowchart ends. 

When the TKI_POB_ATR shows shuffle mode, the 
processing advances from step S405 to step S415, where the 
variable i is initialized, and to step S416, where the CPU 
10 generates a random number r in a range from 1 to POB_Ns. 

In step S418, the CPU 10 checks whether the newly 
generated random number r matches one of the used POB numbers 
that has been previously stored. If so, the processing 
returns to step S4 16 where the random number r is regenerated. 
If not, the processing advances from step S418 to S419 where 
the POB file specified by the r^^ TKI_POB_SRP corresponding 
to the random number r is displayed for the display time 
POB_time determined in step S404. After this, in step S417 
the CPU 10 stores the random number r as a used POB number. 

As in random mode, when the extension of the POB file 
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specified by the TKI_POB_SRP is "JPG", the POB is displayed 
as it is. Conversely, when the extension of the POB file 
specified by the TKI_POB_SRP is "SPl", the POB file will 
be in an encrypted state, so that the CPU 10 reads the FileKey 

5 corresponding to the POB file from the protected area, 
decrypts the POB file using the encryption key, and displays 
the POB. When this display ends, in step S420 the CPU 10 
judges whether the variable i has reached the value given 
in POB_Ns. If not, the processing proceeds to step S421, 

10 where the variable i is incremented, and then returns to 
step S416. The processing in steps S416 to S421 is hereafter 
repeated until the variable i reaches the value given in 
POB_Ns, When the variable i reaches the value given in 
POB_Ns, the processing in this flowchart ends. 

15 

{95-1} Flowchart of the Background Image Display Procedure 

The procedure for displaying a foreground image is 
as described above and the following describes the procedure 
for displaying a background image. FIG. 95 is a flowchart 
20 for the background image display procedure . This flowchart 
contains fundamentally the same processing as the flowchart 
in FIG. 94, with the processing being performed according 
to the DPLI_POB_SRPs and DPLI_POB_ATR in the DPLGI instead 
of the TKI_POB_SRPs and TKI_POB_ATRs in the TKGI. 
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When the Default_Playlist_Information is selected^ 
the CPU 10 performs the processing in steps S502 to S505. 
As in steps S402 to S405, the CPU 10 judges whether the 
DPLI_POB_SRPs included in the DPLGI specify any POBs . When 
5 one or more POB files are specified^ the CPU 10 counts the 
number of POB files that are specified, calculates the 
display time POB_time showing the display period to be used 
for each POB file, and then determines the display mode 
to be used for displaying the POB files • 

10 When the DPLI_POB_ATR shows sequential mode, the CPU 

10 performs step S506 to step S509 . As in step S406 to S409, 
POB files are sequentially displayed in order in accordance 
with a DPLI_POB_SRP, out of the DPLI_POB_SRPs included in 
the DPLGI, indicated by the variable i. 

15 When the DPLI_POB_ATR shows random mode, the CPU 10 

performs step S510 to step S514, As in step S410 to S414, 
POB files are displayed in a random order in accordance 
with a DPLI_POB_SRP, out of the DPLI_POB_SRPs included in 
the DPLGI, indicated by the random number r. 

20 When the DPLI_POB_ATR shows shuffle mode, the CPU 10 

performs step S515 to step S521. As in step S415 to S421, 
POB files are displayed in a random order with no repetition 
in accordance with a DPLI_POB_SRP, out of the DPLI_POB_SRPs 
included in the DPLGI, indicated by the random number r. 
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{96-1} Flowchart of the Background Image Display Procedure 

This completes the background image display procedure 
that is performed based on the DPLI_POB_SRPs in DPLGI • The 
5 following describes the background image display procedure 
that is performed based on the PLI_POB_SRPs in a PLGI . FIG. 
96 is a flowchart showing the background image display 
procedure based on the PLI_POB_SRPs . With the exception 
of the processes based on DPLI_POB_SRPs being performed 
10 based on PLI_POB_SRPs^ this flowchart is exactly the same 
as the flowchart in FIG. 95, so that the processes have 
been given the same reference numerals . No explanation of 
FIG. 96 will be given. 

1 S { 94-2_95-2_97A , B , C } Example Display Screens on the LCD Panel 
5 

FIGS. 97A to 97C show what kind of combined images 
are displayed on the LCD panel 5 when a foreground image 
specified by a TKI_POB_SRP and a background image specified 
20 by the DPLGI are displayed according to the display 
procedures shown in the flowcharts in FIGS. 94 and 95. 

In the example in FIG. 97A, assume that the user 
indicates the Default_Playlist_Information and that the 
display of POBs begins in accordance with the playback order 
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given in this playlist. The foreground image display 
procedure shown in FIG. 94 and the background image display 
procedure shown in FIG. 95 are performed and the POBs 
specified for display by the TKI_POB_SRPs in the TKGI and 
5 the POBs specified for display by the DPLI_POB_SRPs in the 
DPLGI are displayed one after another. At a point six 
minutes after the start of playback, images are combined 
as shown in FIG. 80 and the combined image shown in FIG. 
97B is displayed on the LCD. panel 5. 
10 At a point sixteen minutes after the start of playback, 

images are combined as shown in FIG. 81 and the combined 
image shown in FIG. 97C is displayed on the LCD panel 5. 

{ 94-2_96-l_98A, B , C } Example Display Screens on the LCD Panel 
15 5 

FIGS. 98A to 98C show what kind of combined images 
are displayed on the LCD panel 5 when a foreground image 
specified by a TKI_POB_SRP and a background image specified 
by a PLI_POB_SRP are displayed according to the display 
20 procedures shown in the flowcharts in FIGS. 94 and 96. 

In the example in FIG. 31 A, assume that the user 
indicates a PLI and that the display of POBs begins in 
accordance with the playback order given in this playlist. 
The foreground image display procedure shown in FIG. 94 
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and the background image display procedure shown in FIG. 
96 are performed and the POBs specified for display by the 
TKI_POB_SRPs in the TKGI and the POBs specified for display 
by the PLI_POB_SRPs in the PLGI are displayed one after 

5 another. At a point six minutes after the start of playback, 
images are combined as shown in FIG. 85 and the combined 
image shown in FIG. 98B is displayed on the LCD panel 5. 
At a point sixteen minutes after the start of playback, 
images are combined as shown in FIG. 86 and the combined 

10 image shown in FIG. 98C is displayed on the LCD panel 5. 



{99_1} Recording Apparatus of the Second Embodiment 

The following describes a recording apparatus of this 
second embodiment. This recording apparatus differs from 
15 that of the first embodiment in that it is capable of recording 
a plurality of POBs onto a flash memory card, of setting 
values in the TKI_POB_SRPs, DPLI_POB_SRPs, and PLI_POB_SRPs, 
and setting values in the TKI_POB_ATR, DPLI_POB_ATR, and 
PLI_POB_ATR. 

20 To perform these processes , the CPU 10 in the recording 

apparatus of this second embodiment executes the procedure 
shown in FIG. 99. The following describes the recording 
procedure executed by the recording apparatus of this second 
embodiment with reference to the flowchart shown in FIG. 
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In step S601, the CPU 10 initializes the various 
variables used in this procedure.' These are the variables 
#x, #y, #z^ #u, #vy, and #w. Of these, the variable #x is 
5 used to specify which POB is presently being processed, 
the variable #y is used to specify which track sequence 
(PLI) is presently being processed, and the variable #z 
is used to specify which track (TKI) is presently being 
processed. The variable #u specifies which of the 

10 DPLI_POB_SRPs is being processed, while the variable #vy 
which of the PLI_POB_SRPs in the PLI (PLI#y) specified by 
the variable #y is being processed. The variable #w 
specifies which TKI_POB_SRPs in the TKI (TKI#z) specified 
by the variable #z is presently being processed. 

15 After initializing these variables, the CPU 10 

advances to step S602 where it displays POB#x. This allows 
the user to visually confirm the photo, illustration, or 
lyric sheet in this POB. In step S603, the CPU 10 asks the 
user to indicate whether the still image data in POB#x is 

20 to be displayed throughout the entire track sequence or 
just during the playback period of a specific track, and 
then receives a user selection. 

When the user judges that POB#x should be assigned 
to a track sequence, in step S604 the CPU 10 waits for the 
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user to indicate the track sequence for which POB#x should 
be displayed. When the user inputs his/her selection^ the 
processing proceeds to step S605 when the CPU 10 judges 
whether the indicated track sequence #y is the DPLI or a 

5 PLI . When the track sequence #y is the DPLI, the processing 
proceeds to S606 where POB#x is set in the DPLI_POB_SRP#u, 
and then to S607 where the DPLI_POB_ATR#u of the DPLI is 
set based on this POB#x. 

Once a DPLI_POB_SRP and the DPLI_POB_ATR have been 

10 set in this way, the CPU 10 increments the variable #u 
(#u-^#u+l) in step S608 and the variable #x {#x-#x+l) in 
step S609. 

When a PLI is selected in step S605, .the processing. 
proceeds to step S 610 where POB#x is set in the PLI_POB_SRP#vy 
15 in PLI#y, and to step S611 where the PLI_POB_ATR#vy for 
this PLI is set based on POB#x. After this, in step S612 
the CPU 10 increments the variable #vy {#vy-^#vy+l) , before 
advancing to step S609 to increment the variable #x 
(#x-»#x+l) . 

20 When, in step S603, the user judges that POB#x should 

be assigned to a specific track, the processing advances 
to step S613 where the CPU 10 receives a user indication 
of this specific track. Next, in step S614, the CPU 10 sets 
POB#x in a TKI_POB_SRP#w set for the TKI#z of the indicated 
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track {track#z) . 

The processing then proceeds to step S615 where the 
CPU 10 sets the TKI_POB_ATR#w of TKI#z based on the POB#x, 
to step S616 where the CPU 10 increments the variable #w 

5 (#w-^#w+l) and to step S617 where the CPU 10 whether the 
variable #x has reached the final number #n in a POB, If 
not, the processing proceeds to step S609 where the CPU 
10 increments the variable #x. If the variable #x has 
reached the final number #n in a POB, the processing proceeds 

10 to step S618 where P0B#1 to POB#n, the TKMG including the 
TKIs, and the PLMG including the DPLI and PLIs are recorded 
on the semiconductor memory card to end the processing. 

In these embodiments, it is possible to have the same 
still image data, such as an artist photo or a record label 

15 logo, displayed as a background image during the playback 
of a plurality of tracks. This is achieved by merely 
specifying the still image data in DPLI_POB_SRPs or 
PLI__POB_SRPs that correspond to such tracks in the 
Default_Playlist_Information or in a PLI. 

20 Still image data, such as a lyrics sheet, that is to 

be displayed with a background image only during the playback 
of a particular track can be specified by a TKI_POB_SRP 
in the TKI of the track. 

The above explanation focuses on what is presently 
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believed to be the ideal system for realizing the concept 
of the present invention^ though it should be obvious that 
several modifications can be made within the scope of the 
invention. Three examples of such are given as (a), (b) 
5 and (c) below. 

(a) The procedures explained using the flowcharts in FIGS . 
94, 95, 96, and 99 can be achieved by programs that may 
be distributed and sold having been recorded onto a recording 

10 medium. 

(b) The present embodiments describe the case where the 
presentation data and navigation data are used for music 
contents, although it should be obvious that such data can 

15 be used for an audiobook that is a recording of an actor 
or announcer reading from a book. In such case, still image 
data that shows text from the book can be ideally specified 
by the TKI_POB_SRPs as the foreground images while the 
illustrations from the book are specified by the 

20 DPLI_POB_SRPs or PLI_POB_SRPs . 

(c) In this second embodiment, the POBs specified by 
DPLI_POB_SRPs and PLI_POB_SRPs are used as background images 
while the POBs specified by TKI_POB_SRPs are used as 
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foreground images^ though the opposite setup may be used. 
Alternatively, when different POBs are simultaneously 
specif ied by a DPLI_POB_SRP or PLI_POB_SRP and a TKI_POB__SRP, 
only one of such POBs may be displayed. As another 
5 alternative, no distinction into "background image" and 
"foreground image" need be used. As one example, a POB 
specified by a DPLI_POB_SRP or PLI_POB_SRP may be displayed 
first, and a POB specified by a TKI_POB_SRP may be displayed 
next. 

10 

THIBD EMBODIMENT 

While the second embodiment. describes the case where 
each POB is displayed for an equal period during the valid 

15 period of a TKI and a PLI, this third embodiment describes 
the case where a phrase timing table and a highlight 
coordinate table are also stored on the flash memory card 
31 so that the display of lyrics can be properly synchronized 
to the playback of a song. 

20 The phrase timing table associates the TKI_POB_SRPs 

specifying the POBs showing each section of the lyrics with 
information showing at what time the corresponding phrase 
begins and ends in a song. FIG. lOOA shows one example of 
the phrase timing table. In this example, "phrase timing" 
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refers to the period during which a phrase given in the 
lyrics of a track is being sung as part of the playback 
of the AOB. This period is expressed to an accuracy of 
milliseconds. In addition to updating the playback time 
code as described in the first embodiment, a playback 
apparatus monitors the phrase timing given in this table 
that corresponds to the current value of the playback time 
code. By monitoring the phrase timing in this way, the 
playback apparatus can know which POB stores the lyrics 
for the AOB, AOB_ELEMENT, and AOB_FRAME currently being 
played back. Using a table that gives the phrase timing 
of a POB in milliseconds in this way allows the playback 
apparatus to synchronize the playback of AOBs and the display 
of lyrics to millisecond accuracy. 

When the user indicates a desired playback start time 
using the jog dial as described in the first embodiment, 
the playback apparatus can find which AOB_FRAME in which 
AOB_ELEMENT in which AOB corresponds to the indicated 
playback start time using Equations 1 to 3 given in the 
first embodiment . The playback apparatus also j udges which 
phrase timing includes the indicated playback start time 
and has the POB corresponding to this phrase timing displayed. 
This means that when the user has playback start from a 
desired position indicated using the jog dial, the 
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appropriate POB for this desired position can also be 
displayed. Note that while the present case states that 
times are given in the phrase timing table, the AOB number, 
AOB_ELEMENT number and AOB_FRAME number of the AOB, 

5 AOB_ELEMENT, and AOB_FRAME to which a phrase should be 
synchronized may be given in the phrase timing table instead • 
On the other hand, the highlight coordinate table 
associates the display coordinates of characters used in 
the lyrics and the timing at which the AOB_ELEMENT and 

10 AOB_FRAMEs corresponding to these characters will be played 
back. FIG. lOOB shows one example of the highlight 
coordinate table. Preparing this kind of highlight 
coordinate table enables a playback apparatus to display 
the characters corresponding to the lyrics, out of the lyrics 

15 displayed according to the phrase timing, in the AOB_ELEMENT 
and AOB_FRAME currently being played back in a different 
color. 

As one example, when the lyrics include the phrase 
"Hey hey boy don't take it slow", the highlight coordinate 
20 table will include display coordinates for the characters 
"H", "e", "y", "h", "e", "y", ... that are associated with 
the playback period of the AOB_ELEMENT and AOB_FRAME 
corresponding to these characters . When playing back an 
AOB, the playback apparatus changes the color of the position 
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shown by the display coordinates of the characters given 
in the highlight coordinate table. 

The playback apparatus can therefore display the 
lyrics in amanner that allows the user to instantly recognize 
5 what part of the AOB is currently being played back. This 
means that music recorded on a flash memory card can be 
played back with highlighted lyrics in the same way as 
conventional karaoke tracks. 

In this third embodiment, the phrase timing table and 

10 highlight coordinate table are provided to enable precise 
synchronization between audio playback and the displayed 
lyrics^ in the same way as conventional karaoke tracks. 
Although the present invention has been fully described 
with reference to the accompanying drawings, it is to be 

15 noted that various changes and modifications will be 
apparent to those skilled in the art. Therefore, unless 
such changes and modifications depart from scope of the 
present invention, they should be construed as being 
included therein. 

20 

Industrial Applicability 

The semiconductor memory card of the present invention 
is especially suited for use in the field of consumer 
electronics as a recording medium for recording music or 
25 other material distributed electronically or otherwise. 
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The recording and playback apparatuses of the present 
invention enable consumers to make full use of this 
semiconductor memory card. 
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CLAIMS 

!• A semiconductor memory card^ storing: 

an audio sequence including a plurality of audio 
5 objects; 

a plurality of still image objects; 
at least one piece of playback route information 
showing an order in which audio ob j ect s , out of the plurality 
of audio objects in the audio sequence, are to be played 
10 back; 

at least one piece of first pointer information, each 
of which corresponds to a piece of playback route 
information and specifies at least one still image object 
that should be displayed when the audio objects in the order 

15 indicated by the corresponding piece of playback route 
information are played back; and 

at least one piece of second pointer information, 
each of which corresponds to an audio object in the audio 
sequence and specifies at least one still image object that 

20 should be displayed only during playback of the 
corresponding audio object. 



2. A semiconductor memory card according to Claim 1, 

wherein at least one audio object is music data, 
25 the plurality of still image ob j ects includes at least 
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one still image object showing lyrics for a song represented 
by music data in an audio object, and 

at least one piece of second pointer information 
specifies each still image object showing lyrics for a song 
5 represented by music data in the audio object corresponding 
to the piece of second pointer information. 



3 . A semiconductor memory card according to Claim 1 , further 
storing 

10 a plurality of symbolic counters, each of which 

corresponds to a still image object and shows whether the 
still image object is specified by any of the at least one 
piece of first pointer information and the at least one 
piece of second pointer information and, if so, how many 

15 pieces of first pointer information and second pointer 
information specify the still image object. 



4. A semiconductor memory card according to Claim 1, 

wherein the plurality of still image objects includes 
20 at least one still image object that has been encrypted, 
and 

the semiconductor memory card further stores: 
management information including identification 
information for each still image object, additional 
25 information showing whether each still image object has 
been encrypted, and a storage position of each still image 
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object; and 

at least one decryption key for use when decrypting 
the at least one encrypted still image object^ the at least 
one decryption key being accessible to a device connected 
5 to the semiconductor memory card only if the device has 
been found to be authentic, 

the pieces of first pointer information and second 
pointer information specifying still image objects using 
the identification information given in the management 
10 information. 

5. A semiconductor memory card according to Claim 4, 
including: 

a protected area that stores the at least one 
15 decryption key and is accessible to a device connected to 

the semiconductor memory card only if the device has been 

found to be authentic; and 

an unprotected area that is accessible to any device 

connected to the semiconductor memory card, 
20 the audio sequence, the plurality of still image 

objects, each piece of playback route information, each 

piece of first pointer information, each piece of second 

pointer information, and the management information being 

stored in the unprotected area, and 
25 the at least one encrypted still image object having 

been encrypted using the at least one decryption key stored 
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in the protected area. 

6. A semiconductor memory card according to Claim 5, 

wherein at least two still image objects, out of the 
5 plurality of still image objects, have been encrypted, 
at least two decryption keys are stored in a 
predetermined order in the protected area as a decryption 
key sequence, and 

the identification information for each encrypted 
10 still image object includes a key number showing a position 
in the decryption key sequence of the decryption key 
corresponding to the encrypted still image object. 

7. A playback apparatus for a semiconductor memory card, 
15 the semiconductor memory card storing (1) an audio 

sequence including a plurality of audio objects, (2) a 
plurality of still image objects, (3) first pointer 
information specifying at least one still image object that 
should be displayed when the plurality of audio objects 

20 in the audio sequence are played back, and (4) at least 
one piece of second pointer information, each of which 
specifies at least one still image object that should be 
displayed only when a particular audio object in the audio 
sequence is played back, 

25 the playback apparatus comprising: 

playback means for playing back audio objects in the 
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audio sequence one at a time in order; 

display means for displaying the at least one still 
image object specified by the first pointer information 
throughout playback of the audio objects in the audio 
5 sequence; and 

control means for having the display means display 
the at least one still image object specified by a piece 
of second pointer information throughout playback of a 
particular audio object corresponding to the piece of second 
10 pointer information. 

8. A playback apparatus according to Claim 7, 

wherein the control means has the display means 
display a combined image produced by combining the at least 
15 one still image object specified by the piece of second 
pointer information with the at least one still image object 
specified by the first pointer information, 

9. A recording apparatus for a semiconductor memory card 
20 that stores a plurality of still image objects and an audio 

sequence including a plurality of audio objects^ 
the recording apparatus comprising: 
assigning means for assigning to the audio sequence 
at least one still image object that is to be displayed 
25 throughout playback of the plurality of audio objects, and 
assigning at least one still image object that is to be 
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displayed throughout playback of a particular audio object 
to the particular audio object; and 
recording means for recording 

(1) first pointer information showing the at least 
5 one still image object assigned to the audio sequence, and 

(2) second pointer information showing the at least 
one still image object assigned to the particular audio 
object 

onto the semiconductor memory card. 

10 

10. A computer-readable storage medium storing a program 
that has a computer execute a playback procedure for a 
semiconductor memory card, the semiconductor memory card 
storing (1) an audio sequence including a plurality of audio 

15 objects, (2) a plurality of still image objects, (3) first 
pointer information specifying at least one still image 
object that should be displayed when the plurality of audio 
objects in the audio sequence are played back, and (4) at 
least one piece of second pointer information, each of which 

20 specifies at least one still image object that should be 
displayed only when a particular audio object in the audio 
sequence is played back, 

the program comprising: 

a playback step for playing back audio objects in 
25 the audio sequence one at a time in order; 

a display step for displaying the at least one still 
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image object specified by the first pointer information 
throughout playback of the audio objects in the audio 
sequence; and 

a control step for having the display step display 
5 the at least one still image object specified by a piece 
of second pointer information throughout playback of a 
particular audio ob j act corresponding to the piece of second 
pointer information. 

10 11. A computer-readable storage medium according to Claim 
10, 

wherein the control step has the display step display 
a combined image produced by combining the at least one 
still image object specified by the piece of second pointer 
15 information with the at least one still image object 
specified by the first pointer information. 

12. A computer-readable storage medium storing a program 
that has a computer execute a recording procedure for a 
20 semiconductor memory card that stores a plurality of still 
image objects and an audio sequence including a plurality 
of audio objects, 

the program comprising: 

an assigning step for assigning to the audio sequence 
25 at least one still image object that is to be displayed 
throughout playback of the plurality of audio objects, and 
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assigning at least one still image object that is to be 
displayed throughout playback of a particular audio object 
to the particular audio object; and 
a recording step for recording 

(1) first pointer information showing the at least 
one still image object assigned to the audio sequence, and 

(2) second pointer information showing the at least 
one still image object assigned to the particular audio 
object 

onto the semiconductor memory card. 

13. A playback method for playing back data from a 
semiconductor memory card,, the semiconductor memory card 
storing (1) an audio sequence including a plurality of audio 
objects, (2) a plurality of still image objects, (3) first 
pointer information specifying at least one still image 
object that should be displayed when the plurality of audio 
objects in the audio sequence are played back, and (4) at 
least one piece of second pointer information, each of which 
specifies at least one still image object that should be 
displayed only when a particular audio object in the audio 
sequence is played back, 

the playback method comprising: 

a playback step for playing back audio objects in 
the audio sequence one at a time in order; 

a display step for displaying the at least one still 
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image object specified by the first pointer information 
throughout playback of the audio objects in the audio 
sequence; and 

a control step for having the display step display 
5 the at least one still image object specified by a piece 
of second pointer information throughout playback of a 
particular audio object corresponding to the piece of second 
pointer information. 

10 14. A playback method according to Claim 13, 

wherein the control step has the display step display 
a combined image produced by combining the at least one 
still image object specified by the piece, of second pointer 
information with the at least one still image object 

15 specified by the first pointer information. 

15 • A recording method for a semiconductor memory card that 
stores a plurality of still image objects and an audio 
sequence including a plurality of audio objects, 

20 the recording method comprising: 

an assigning step for assigning to the audio sequence 
at least one still image object that is to be displayed 
throughout playback of the plurality of audio objects, and 
assigning at least one still image object that is to be 

25 displayed throughout playback of a particular audio object 
to the particular audio object; and 
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a recording step for recording 

(1) first pointer information showing the at least 
one still image object assigned to the audio sequence, and 

(2) second pointer information showing the at least 
5 one still image object assigned to the particular audio 

object 

onto the semiconductor memory card. 
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FIG. 1 
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FIG. IIA 



MPEG2-AAC format 



format 


Audio_Data_Transport_Sueam(ADTS) 


Profile 


Low ComplexitylLUj protilelmandatory) 


bitrate per channel** 


between lbkbit/s(min.Jand /iJkbit/stmax.) 
Other bitrates are optional. 


sampling_frequency 


48kHz(mandatoiy) 
44.1 kHz(mandatory) 
32 kHz(mandatoiy) 
24 kHz(mandatoiy) 
22.05 kHz(mandatoiy) 
16kHz(mandatory) 


channel_configuration 


single_channel_element(mandatoryj 
channel_pair_element{mandatory) 


number_oLclata_blocksJnJrame 


1 header/ 1 raw_data_blocklmandatoiyj 


FIG. IIB , 

MPEG layer 3 format 


format 


MPtG-1 layers 

MPEG-2 layer 3 low samplino frequency 


bitrate per channel'* 


MPtG l:between ibkbit/sand9bkbit/s 
MPEG 2 LSF:between 16kbit/s and 80kbit/s 
Other bitrates and variable bitrate are optional. 
Bitrate index "0000" .i.e. "free format" is not supported. 
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mode 
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joint_stereo 

single_cannel 


FIG. lie Windows Media Audio format 


fomiat 


Windows Media Audio foimat 


bitrate per channel" 


between Skbit/s and 80kbit/s 
Other bitrates are optional. 
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FIG. 14 
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FIG. 80 



POB004. SPl 

TrackB LYRICS 



Hey hey boy don't take it slow 
Come here and give me lovin' 
Hit me with your freaky style 
Let's get this love thing goin' ! 




POB022. SPl 

ARTIST PHOTO 




Hey hey boy don't take it slow 
Come here and give me lovin' 

. . " 

(Hit me mihj/om^ freakj style 
Let's get this love thing goin' ! 
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FIG. 81 



POBOIO TrackD (1/4) LYRICS POB026 IMAGE FROM PROMO VIDEO 



Sophisticated lady 
Come feel my love, my woman 
I'll give you pearls and diamonds 
I'll show you round my world 




Sophisti^^^^ ^^ i^yj^ 
Come feel my love, my woman 

/liiK ^7f/ 

pearls and diar 
I'll show you round my world 



rU give you jDearls and diamonds 
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FIG. 85 



POB004. SPl 
TrackB LYRICS 



POB042 

PET PHOTO 



Hey hey boy don't take it slow 
Come here and give me levin' 
Hit me with your freaky style 
Let's get this love thing goin' ! 






Hey hey boy don^tjake it slow jl 



Come here and give me lovin' 
f Hit me with your freaky style 



Let's get this love thing goin' 



IMAGE FORMED BY COMBINING 
POB004 SPECIFIED BY PLI#1 WITH POB042 
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FIG. 86 



POBOlO TrackD (1/4) LYRICS POB046 HOLIDAY SNAP 

FROM EUROPE 




IMAGE FORMED BY COMBINING 
POBOlO SPECIFIED BY PLI#1 WITH POB046 
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FIG. 90 
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FIG. 93A 




FIG. 93B 



GRAPHIC PLANE 1 



GRAPHIC PLANE 0 
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FIG. 97A 



MENU : 




PLAYLIST#1 




PLAYLIST#2 




PLAYLIST#3 




PLAYLIST#4 





FIG. 97B 



SIX MINUTES AFTER 
START OF PLAYBACK 




Hey hey boy don't take it slow 

J^jCj f I 

-Come here and give me lovin' 

'Hit me with your freaky style 

/A \ 
Let's get this love thinggoin' ! 



FIG 970 

SIXTEEN MINUTES AFTER 
START OF PLAYBACK 




Come feel my love, my woman 
///)! \ ^ /A/ 

I'll give you pearls and diamonds 

'77/ f/^ 
I'll show you round my world 
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FIG. 98A 



MENU: 

DEFAULTPLAYLIST 



PLAYLIST#2 
PLAYLIST#3 
PLAYLIST#4 



FIG. 98B 



SIX MINUTES AFTER 
START OF PLAYBACK 



FIG. 98C 




Hey hey boy don't take it slow ^ 

— I n 

Come here and give me lovin' 

( I 

\Hit me with your fr eaky style ; 



Let's get thisjovethirig^oiri 



SIXTEEN MINUTES AFTER 
START OF PLAYBACK 




7 Sophisticated lady V ] 



*,Come feel my love, my woman 

^ xrr n( \ IK I i 

I'll give you pearls and diamonds 
1 11 show you round my world 
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FIG. 99 cvrmr^ 

rVARlAmES INI'I'IALIZED S60i 

1^5602 



TRACK 



ISPOB#x ^^^S603 
STILL IMAGE DATA THA" 
Is TO BE DISPLAYED DURING THE 
PLAYBACK PERIOD OF THE ENTIRE 
SEQUENCE OR STILL IMAGE DATA 
THAT IS TO BE DISPLAY DURING 
[HE PLAYBACK PERIOD OF 
.PARTICULAR 

j:back2 

TRACK 
SEQUENCE 



WAIT 



WAIT FOR 
'USER SELECTION OF THE 
TRACK SEQUENCE DURING 
^ICHPOBKxISTO 
tSPLAYEl 



S604 



PLI 



;THE PLAYLET 
E^ICATED BY THE SELECIEl 
JRACK SEQyENCE#y THE 
.MORA 



S605 



.S606 



urn . 

I POBfecSEriNIADPLl POb SRPIulNTHEPlfr n 

' I JL S60 7 

DPLI PQB ATR#u FOR THE DPLI SET BASED ON POB#n 



#u 



#u + 1 



S608 



I #x" 



'8609 



I POBtx SET IN A PLI i^Ok SkP#w IN THE PLI^ 
' ■ I" ' "rese ll 

IPLi PQB ATR#wFOkPL #vSKTBASEDONPan#x i 



#x + 1 



i/AiTFOR ^""--^.^seia 

"USER SELECTION OF TRACT 
FOR WHICH POBfxISTO 

LDISPLAYFn 'i^LLECTION 

MADE ^8614 



WAIT 



POK#x SET IN TKJ_PUB_SKP#w SPKCIFIEU 
FOR TKI#z FOR THE SELECTED TRACK#z 



i'Ki_PUB_A'l'k#w IN iKlffz kfci BAbbu UN puttffx" 

8617 

fx^ASTNUMBEir N^ 



'S615 
=1 




POBs #110 In. RMG INCLUDING Tl^ DPU AND Hi AND TKMG 1 
INClIJim;TIffiTKbREa3U)ED(>l THE FIASHMB>>PRY CARD j 
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FIG. lOOA PHRASE TIMING TABLE 



(LPOB.SRPtI 
TKI_P0B_SRP#2 
TKI_P0B_SRP#3 
TKIf2 



PHRAS 
PHRA5 
PHRASE 
PHRAf" 



DISPL. 
DISPL 
DISPL 
DISPL 



AY START OminO.OOOsec 
AYEND2minl.800sec 
AY START2minl.801sec 
AY END4min3.600sec 
AY START 4min3.601sec 
AYEND6inin6.0l)0sec 



_P0B_SRP#1 
TKI.P0B_SRP#2 
TKI_P0B_SRP#3 
TKIfS 

TKI_P0B_SRP#1 
TKI.P0B.SRP#2 
TKI POB SRP#3 



RASE D 

RASE d: 

RASE p 

~ E d: 
E d: 

RASED 




AYSTARTOminO.OOOsec 
AYENDlmin6.000sec 
AY START lmin6.001sec 
AY ENp2minl2.000sec 
^AY START 2minl2.{)0Isec 
LAYEND3minl8.000sec 



E DISPLAY START Omin O.OOOsec 
E DISPLAY END linin49.800sec 
E DISPLAY STARTlniin48.901sec 
E DISPLAY END 3min39.6{)0sec 
E DISPLAY START3min39.601sec 
E DISPLAY END 5min30.000sec 



FIG. lOOB 



HIGHLIGHT COORDINATE TABLE 



TKI#2. TKI POB SRP#1 
DISPLAY 

COORDINATES OF CHARACTERS 
X.Y COORDINATES OF "H" 
X.Y COORDINATES OF 
X.Y COORDINATES OF 
X.Y COORDINATES OF 
X.Y COORDINATES OF 
X.Y COORDINATES OF 
X.Y COORDINATES OF 
X.Y COORDINATES OF 
X.Y COORDINATES OF 
X.Y COORDINATES OF "d" 
X.Y COORDINATES OF "o" 
X.Y COORDINATES OF "n" 
X.Y COORDINATES OF"' ' 
X.Y COORDINATES OF "t" 
X.Y COORDINATES OF "t" 
X.Y COORDINATES OF "a" 
X.Y COORDINATES OF "k" 
X.Y COORDINATES OF "e" 



y 

"h" 



y 

"b" 
"o" 

It n 

y 



PHRASE START TIME 
OminlO.OOOsec 
OminlO.OOOsec 
OminlO.OOOsec 
Ominl2.000sec 
Ominl2.000sec 
OminlZ.OOOsec 
OminlS.OOOsec 
OminlS.OOOsec 
OminlS.OOOsec 
OminlS.OOOsec 
OminlS.OOOsec 
OminlS.OOOsec 
OminlS.OOOsec 
OminlS.OOOsec 
Ominie.OOOsec 
Ominie.OOOsec 
Ominie.OOOsec 
Ominie.OOOsec 



100/100 



INTERNATIONAL SEARCH REPORl 



Ir. atlonal Application No 

PCT/JP 00/03300 



A. CLASSIFICATION OF,SUBJECT MATTER , 

IPC 7 G11C7/00 H04N1/21 



According to International Patent Qassflteatton (IPC) or to both national dassification and IPC 



B. FIELDS SEARCHED 



Minfmum doctmentation seaiched (classification system foaowed by dassifioatkyi symbols) 

IPC 7 GllC GllB G06F H04N 



Documentation seaiched other than minimum documentation to the extent that such documents are included in the fields seaiched 
Bectronic data base consumed during the intemationai search (name of data t»se and, where practical, search terms used) 

EPO-Internal , MPI Data, PAJ 



a DOCUMEKTS CONSIDERED TO BE RELEVANT 



Category" Citation of document, with indication, where appropriate, of the relevant passages 



Relevant to daim No. 



GB 2 300 286 A (SAMSUNG ELECTRONICS CO 
LTD) 30 October 1996 (1996-10-30) 

figures 1,8 

EP 0 840 506 A (SONY CORP) 
6 May 1998 (1998-05-06) 

figures 5,8 

US 5 892 975 A (BARNES THOMAS J) 
6 April 1999 (1999-04-06) 

column 4, line 44-46; claims 3,7 



-/- 



1.7.9, 
10,12, 
13,15 



1,7,9, 
10,12, 
13,15 



1.7.9, 
10,12, 
13,15 



Further documents are listed in the continuation of box C. 



j)( j Patent f^ty members are listed m annex. 



Special categories of cited documents : 

"A' document defining the general state of the art which is not 

considefBd to be of particular relevance 
*E* earlier document but published on or after the inteniationa] 

fiBng date 

V document wWch may throw doubts on priority daim(8) or 
which is dted to establish the publication date of arwther 
citation or other spectat reason (as specified) 

"O' document referring to an orat (fisdosure. use, exhSxtionor 
other means 

"P' document pubashed prior to the Intemationai f&ing date but 
later tlian the priority date daimed 



T* later document published after the intemationai filing date 
or priority date and not in conflict with the application but 
cited to understand tfie priiviple or theory underlying the 
invention 

*X* document of particular relevance: the dainned irrvarvtion 
cannot be cor^idersd novel or cannot be considered to 
invdve an inventive step when the document is talcen alone 

*Y* dociment of particular relevance: the daimed invention 
canrxjt be considered to involve an inventive step when the 
document is combined with one or more other such docu> 
ments. such combination being obvious to a person sidlled 
in the art 

*&* document member of the same patent famiy 



Date of the actual completion of the International search 



20 September 2000 



Dateof maiitng of the International search report 



04/10/2000 



Name and malting address of the ISA 

European Patent OfRce. P.B. 5818 PatenHaan 2 

NL-2280HVRijswijl( 

Td. (401-70) 340-2040. Tx. 31 651 epo nl. 

Fax: (431-70) 340-3016 



Authorized officer 



Vidal Verdu, J. 



tarn PCT/ISAaiO(«aoandd«M) (July 1992) 



INTERNATIONAL SEARCH REPORT 



liv ational Application No 

PCT/JP 00/03300 



a(Conttnuatlon) DOCUMEMTS CONSIDERED TO BE RELEVAKT 



Categoiy " Citatlcn of document with indlcailon.where appropriate, of the. relevant passages 



Relevant to dalm No. 



EP 0 802 688 A (HITACHI LTD) 
22 October 1997 (1997-10-22) 

figures 7,19 

US 5 815 201 A (HASHIMOTO TETSUYA ET AL) 
29 September 1998 (1998-09-29) 

claims 18,26; figure 12 



1.7.9. 
10,12, 
13,15 



1.7.9, 
10,12. 
13,15 



fom PCTytSAAlO (oanflruatian d saoond shaat) (Aiy 1992) 



INTERNATIONAL SEARCH REPORT 

litfonnatlon on patant family members 



In atlonal 

PCT/JP 



Application No 

00/03300 



Patent document 
cfted in search report 



Publication 
date 



Patent family 
member(8) 



Publication 



UD COUUcOO 


A 




1770 


CN 

IK 


iDOU<fJ D 

1138722 A 
i;qi 10*^1 A 

07ilUoi n 


iD 1 1 l770 

25-12-1996 

UO UU 4777 


EP 0840506 


A 


06-05- 


■1998 


JP 


10136299 A 


22-05-1998 


US 5892975 


A 


06-04- 


•1999 


NONE 






EP 0802688 


A 


22-10- 


•1997 


JP 


10004535 A 


06-01-1998 


US 5815201 


A 


29-09- 


-1998 


OP 
JP 
JP 
US 
EP 


8228321 A 
8237526 A 
8298614 A 
5815205 A 
0729266 A 


03-09-1996 
13-09-1996 
12-11-1996 
29-09-1998 
28-08-1996 



Form PCT/ISAaiO (patant famlyannaiO (July I99e) 



